Skip to content

fix(testnet): bump PER_PP_OPEN_TIMEOUT_MS 60 → 300s + wire run-all.sh URL exports#114

Merged
AquiGorka merged 1 commit into
mainfrom
fix/per-pp-open-timeout-300s
Jun 9, 2026
Merged

fix(testnet): bump PER_PP_OPEN_TIMEOUT_MS 60 → 300s + wire run-all.sh URL exports#114
AquiGorka merged 1 commit into
mainfrom
fix/per-pp-open-timeout-300s

Conversation

@AquiGorka

Copy link
Copy Markdown
Contributor

Two wiring fixes evidenced by 5x deployed-testnet sweep

1. events-capture/subscribe.ts: PER_PP_OPEN_TIMEOUT_MS 60 → 300 s

Sweep 5 of today's deployed-testnet run:

✅ Testnet E2E passed in 539.4s
...
[events-capture] subscriber error:
  perPp:GCBPHSN4...: per-PP WS gave up after 60000ms:
  PP GCBPHSN4... never appeared in dashboard view

Script flow took 539 s end-to-end. PP registration sits at steps 8–9 of the 12-step flow — well past the 60 s the per-PP WS subscriber was willing to wait. Local stack (./testnet/run-local.sh) runs in ~80 s, so 60 s was fine there; deployed testnet is naturally 5–10× slower because of the upstream council-platform load issues (Tempo trace 44207a4b4cacf8c1101cc4332076ee2c shows individual handler spans hitting the 30 s postgres-js connect_timeout ceiling — council-platform fix landing in a separate PR there).

300 s gives the harness 5 minutes of patience — covers the observed worst-case testnet latency, still fails loud rather than hanging indefinitely.

2. testnet/run-all.sh: export PROVIDER_URL / COUNCIL_URL / NETWORK_DASHBOARD_PLATFORM_URL

The events-capture harness (harness.ts:316-319) defaults its providerUrl and networkDashboardUrl to http://localhost:3010 and http://localhost:3035. The flow scripts (testnet/main.ts:163-166, lifecycle/testnet-verify.ts) default their PROVIDER_URL / COUNCIL_URL constants to the deployed-testnet URLs.

Without an explicit export, the harness and the script disagree on which backend to talk to. Symptom on a fresh shell with no local stack running:

[events-capture] script=testnet-main ppPublicKey=GBGDKXUV...
error: Uncaught (in promise) TypeError: error sending request for url
(http://localhost:3010/api/v1/dashboard/auth/challenge): Connection refused (os error 61)

Setting them at the wrapper level keeps the harness and script in lock step against deployed testnet. Caller can override any one for mainnet / local-debugging via the ${X:-default} shape.

Test plan

  • deno fmt, deno lint, deno check events-capture/subscribe.ts clean
  • After merge + paired council-platform pool-bump landing: re-run ./testnet/run-all.sh 5x against deployed testnet. Expect the per-PP gave up failure to be gone; combined with the council-platform fix, expect the council-platform 401/500 endpoints to land in normal time too.

Companion PR

Paired with council-platform PR (postgres pool size 10 → 30, root cause of testnet's slow handlers). Both are needed for the deployed-testnet 5x sweep to clear.

… URL exports

Two related wiring fixes that 5x deployed-testnet sweep evidence required.

## subscribe.ts — PER_PP_OPEN_TIMEOUT_MS 60 → 300 s

60 s was sufficient on local stack (`testnet/run-local.sh` flow ~80 s
end-to-end). On deployed testnet the flow regularly runs 4–9 minutes
under council-platform load:

  Tempo trace 44207a4b4cacf8c1101cc4332076ee2c:
    `✅ Testnet E2E passed in 539.4s`
    individual handler spans hitting 30 s ceiling (postgres-js
    connect_timeout — fix landing separately on council-platform).

PP registration sits behind those slow handlers (steps 8–9 of the flow),
so the per-PP subscriber's 60 s open-patience expired before the PP
existed in provider-platform's dashboard view. Captured shape:

  [events-capture] subscriber error:
    perPp:GCBPHSN4...: per-PP WS gave up after 60000ms:
    PP GCBPHSN4... never appeared in dashboard view

300 s covers the observed worst-case testnet latency, still fails loud
rather than hanging.

## run-all.sh — export PROVIDER_URL / COUNCIL_URL / NETWORK_DASHBOARD_PLATFORM_URL

Harness defaults to `localhost:3010/3015/3035`. The deployed-testnet
flow scripts default to testnet URLs internally, so without an explicit
export the harness and script disagree on which backend to talk to.
Symptom on a fresh shell with no local stack running: harness's
`acquireOperatorJwt` call fails with `Connection refused` to localhost
while the script silently uses testnet for everything else.

Setting them at the wrapper level keeps the harness and script in lock
step against deployed testnet. Caller can still override any one for
mainnet / local debugging via `${X:-default}` shape.
@AquiGorka AquiGorka merged commit d2d592a into main Jun 9, 2026
7 checks passed
@AquiGorka AquiGorka deleted the fix/per-pp-open-timeout-300s branch June 9, 2026 17:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant