start-http-registry

name	start-http-registry
description	Start the local HTTP registry server for development. Use when testing infra scripts or commands that need a Abacus work private overrides such as RPC URLS.

Start HTTP Registry Server

Start the http-registry server in the background.

Instructions:

1. First, find the monorepo root (working directory may have drifted):

   git rev-parse --show-toplevel
   

2. Run the command with run_in_background: true, prefixing with cd to the monorepo root AND CI=false inline (see next paragraph for why):

   cd <MONOREPO_ROOT> && CI=false pnpm -C typescript/infra start:http-registry
   

   --writeMode (optional): append --writeMode when the calling skill will write artifacts back through the server — warp deploy, warp apply, and warp alt create persist the resulting config/addresses via the write routes. Omit it for read-only flows (warp read, warp check). Serving private/pinned RPCs (the reason to use the HTTP registry at all) is independent of --writeMode; the flag only enables the write routes.

   Why CI=false: the infra HTTP registry wraps getRegistryForEnvironment (typescript/infra/config/registry.ts:192), which merges filesystem chain metadata with per-chain RPC overrides. The override source is CI-gated: CI !== 'true' → GCP Secret Manager (private / keyed URLs like Alchemy, Dwellir, Ankr, TronGrid); CI === 'true' → MAINNET3_<CHAIN>_RPC_URLS env vars (the GitHub-Actions injection path). On Haggis workers and any environment where those env vars aren't set, CI=true silently falls back to the public on-disk registry URLs — which are rate-limited (e.g. Tron's public trongrid.io = 3 rps unauthenticated → 429 during broadcasts). Prefix inline so the setting is scoped to this single invocation; do NOT export CI=false globally — other flows in the same session may legitimately need CI=true.

3. Wait for the log line Server running in the background task's output before any downstream consumer hits the server. This is the canonical readiness signal.

4. Verify the server is reachable using the /readiness endpoint, NOT the root path — the root returns 404 by design and is not a liveness signal:

   curl -sf http://localhost:<port>/readiness && echo "ok"
   

   The server only routes specific paths: /readiness, /metadata, /addresses, /chains, /chain/<name>, /warp-route/deploy/<id>, /warp-route/deploy?<filter>, etc. Hitting http://localhost:<port>/ returns 404 even when the server is healthy. Do NOT interpret a root-404 as "server is dead" and fall back to passing the local FS registry path to downstream --registry flags — falling back bypasses the centralized RPC config the HTTP registry provides and can cost real mainnet gas on retries against flaky public RPCs.

5. Report the task/shell ID + the port (typically 3333, read from the logs) to the user.

6. Remind the user they can stop it later with KillShell using that ID, or via /stop-http-registry.

Example output:

Started http-registry server in background (shell ID: shell_abc123) on http://localhost:3333. Readiness verified. To stop it later, I can use KillShell or you can run /stop-http-registry.