Repository navigation
fix(server): T3 Connect no longer waits a cooldown for a tunnel it already replaced - #29542
Draft
chrischriscris wants to merge 1 commit into
Draft
chrischriscris wants to merge 1 commit into
chrischriscris wants to merge 1 commit into
Conversation
…dy replaced The runtime keeps requesting recovery while one waits out its cooldown, so the queue still holds a request for the tunnel that recovery replaced. That request doubled the cooldown, slept it out, did nothing, and still counted as a recovery, delaying the real one by up to 30 minutes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Written by Claude Opus 5.5 on behalf of Christopher
Problem
After a recovery that had to wait out its cooldown, T3 Connect can stay down for another full cooldown, up to 30 min. Logs and timeline in #29541.
While a recovery waits, the runtime keeps requesting recovery for the same tunnel, so the sliding queue still holds a request for the tunnel that recovery just replaced. The runner doubles the cooldown for it, sleeps it out,
recoverManagedTunnelreturnsfalsebecause the config is stale, and the no-op still gets recorded as a recovery. The request for the new tunnel then waits again.Change
makeManagedTunnelRecoveryremembers the config the last successful recovery replaced and skips requests for it before the cooldown, without touching the cooldown or the last-recovery time.recovernow has to return a boolean, whichrecoverManagedTunnelalready does.I kept the check in the runner instead of reading the stored config there: the runner has no access to it, and the stale request is always for the tunnel that was just replaced. A request that goes stale some other way (a relink during the wait) still hits the existing check in
recoverManagedTunnel, unchanged.Scope and approval
Fixes #29541, which isn't triaged yet. I think this fits the small focused fix exception: one module, and the backoff from #22108 is unchanged for real requests. Requests for an already-replaced tunnel just stop consuming it. Happy to wait for triage if you'd rather.
Verification
managedTunnelStartup.test.ts: recover tunnel A, then request A again. On main the second request sleeps the doubled cooldown and callsrecoveragain (fails: expectedfalse, gottrue). With the fix it returnsfalsestraight away andrecoverruns once.vp run check:changedpasses (format, lint, knip, typecheck, tests beside the change).Claude Opus 5.5 in Claude Code (running in T3 Code)