Escalate a tunnel failure that retrying cannot fix - #6
Merged
Conversation
garethx
marked this pull request as ready for review
August 12, 2026 10:16
garethx
force-pushed
the
tests/tools-coverage
branch
from
August 12, 2026 10:20
db29562 to
609e626
Compare
#4 suggested three fixes. Two of them landed with #3 — doctor now compares the CLI's project against the API key's, and the gateway authenticates a CLI config of its own. This is the third, which did not. `no connection found matching filter` will never come right by being retried. The supervisor treated it exactly like a network blip: warning level, doubling backoff, nothing new said each time. That is how "the gateway is receiving no events" stays invisible while everything above the tunnel lines reads healthy. Three consecutive runs too short to count as healthy now log once at error level, with the CLI's own last lines and, for the failures we recognise, the likely cause and the command that confirms it. Once per streak, not per restart, so the log does not fill up; a healthy run re-arms it, so a second outage is not silent. The output tail is reset per run — carrying it over would name a cause that had since been fixed, which is worse than naming none. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
garethx
force-pushed
the
fix/cli-project-mismatch
branch
from
August 12, 2026 10:23
bb7a68b to
d09de3d
Compare
garethx
changed the title
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
1 participant
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.
Rewritten after #3 merged. #4 suggested three fixes; two of them landed with #3, so this PR is now only the third.
doctorcompares the CLI's project against the API key's_check_cli_project) — dropped from this PRhookdeck listenat a gateway-owned configauthenticate()mints the session too — dropped from this PRStacked on #5, which it shares tunnel tests with.
What is left to fix
no connection found matching filterwill never come right by being retried. The supervisor treated it exactly like a network blip — warning level, doubling backoff, nothing new said on each pass. That is how "the gateway is receiving no events" stays invisible while everything above the tunnel lines reads healthy:Three consecutive runs too short to be healthy now produce one error:
Once per streak rather than per restart, so the log does not fill up. A healthy run re-arms it, so a second outage is not silent. Unrecognised output escalates without a cause rather than guessing one — sending an operator after the wrong thing is worse than saying less.
The output tail resets per run: carrying it across would name a cause that had since been fixed, which is the worst kind of wrong because it looks specific.
Verification
299 tests pass, ruff clean. The escalation is mutation-checked — disabling it fails two tests. The tunnel tests replay the exact CLI output from #4.
Also included, since it is the same file and #5's rebase surfaced it:
authenticate()arrived in #3 with no tests and is load-bearing (the adapter refuses to start when it returns False). That coverage is in #5, taking tunnel.py from 81% to 96%.