Skip to content

[muse] fix(server): bound managed-tunnel recovery retry window to 10 minutes - #9

Open
kvnloo wants to merge 1 commit into
mainfrom
muse/managed-tunnel-recovery-retry-window
Open

kvnloo wants to merge 1 commit into
mainfrom
muse/managed-tunnel-recovery-retry-window

Conversation

@kvnloo

@kvnloo kvnloo commented Sep 28, 2026

Copy link
Copy Markdown
Owner

Problem

activateManagedTunnelWithRetry retried retryable connector failures (not-installed, spawn-failed) with an unbounded exponential schedule. server.ts drains recovery requests sequentially (Stream.runForEach), so one persistently failing connector occupied the consumer forever and starved every later recovery request.

Fix

Bound the inner retry schedule with Schedule.upTo using the existing 10-minute MANAGED_TUNNEL_REGISTRATION_RETRY_WINDOW (same calibration as the boot-time registration retries in managedTunnelStartup.ts). After the window, the recovery item fails with the last activation error; server.ts logs it and keeps draining the queue.

Also narrows activateManagedTunnel/activateManagedTunnelWithRetry to the secrets + endpointRuntime dependencies they actually use, and exports the window constant and the retry helper (the helper is exported for tests).

Testing

  • New focused test in apps/server/src/cloud/http.test.ts: a permanently spawn-failing connector forked under TestClock; after advancing 11 virtual minutes the fiber has failed with EnvironmentCloudEndpointUnavailableError instead of still running.
  • Red-on-base: the test fails on the unmodified sources (fiber still running after 11 virtual minutes).
  • Full apps/server/src/cloud/http.test.ts: 46/46 green.
  • vp fmt --check clean on touched files; tsc --noEmit clean for the touched cloud files.

Authored with AI assistance (Muse, Meta's Muse Spark) under the contributor's direction.
Built with Muse Spark / hatch sandbox harness.

…minutes

activateManagedTunnelWithRetry retried retryable connector failures
(not-installed, spawn-failed) with an unbounded exponential schedule.
server.ts drains recovery requests sequentially, so one persistently
failing connector occupied the consumer forever and starved every later
recovery request. Bound the inner schedule with Schedule.upTo using the
existing 10-minute MANAGED_TUNNEL_REGISTRATION_RETRY_WINDOW, so a poisoned
request fails after the window and the queue keeps draining.

Also narrows activateManagedTunnel/activateManagedTunnelWithRetry to the
secrets + endpointRuntime dependencies they actually use, and exports the
window constant and the retry helper (the helper is exported for tests).

Authored with AI assistance (Muse, Meta's Muse Spark) under the
contributor's direction, as documented in the PR description.
@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:S labels Sep 28, 2026
@kvnloo kvnloo added the keep pr-janitor: never auto-close label Oct 17, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

keep pr-janitor: never auto-close size:S vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant