Post the relink URL in the same turn instead of asking for another trigger#153
Merged
Conversation
`invalidate?.().catch(() => {})` swallowed its failure, so a delete that
didn't happen was indistinguishable from one that did -- in the logs and in
the reply. The user is then told to retry, the next attempt resolves the same
dead credential, and it fails identically forever with nothing explaining why.
Verified against the live cluster that the happy path does work: after the
recovery fired, claudeAuthLogin:<subject> was gone while
claudeAuth:<subject> (the setup-token) survived -- the pre-fix code would have
deleted exactly the wrong one of those two. This covers the case where it
doesn't.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KkpJCAfAEi2B3hqfgJhboF
…igger Tested live on #146: the recovery invalidated the stale credential and posted "re-apply the label to try again and I'll post a link for relinking it" -- and nothing else. That is a dead end dressed up as a recovery. The human pays a round trip to receive a link that could have been in the first reply, and on a label-driven run the retry instruction is itself a second manual step, so a single label application produces no actionable output at all. handleAgentTurnFailure now starts the replacement link right after invalidating (in that order -- the reverse would delete the new link too) and returns its URL, using the same pendingIdentityLink/identityLinkPending shape as the first-time link prompt. That arms integration-gateway's existing waitAndResume, so completing the link re-runs the interrupted request automatically: one label, one link, no further triggers. The "re-apply the label" / "send your request again" wording survives only as the fallback for when the replacement flow itself fails to start. The link-prompt markdown is now built by one shared `linkPromptText` for both the first-time and re-link paths, so the two can't drift into describing the same flow differently. `start` is awaited in a try/catch rather than via `.catch()` on its return value: it is only contractually a promise, and a partial IdentityLinkPort would otherwise crash this recovery path outright. Also includes the un-merged follow-up from #152: invalidation failures are logged instead of swallowed, and no longer promise a retry that cannot work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KkpJCAfAEi2B3hqfgJhboF
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.
Follow-up to #152, tested live on #146.
What #152 got wrong
The recovery fired correctly — verified in Redis afterwards:
claudeAuthLogin:<subject>gone,claudeAuth:<subject>(the setup-token) intact, a write-back grant minted. But the only thing posted to #146 was:One label application, zero actionable output. The human pays a round trip to receive a link that could have been in the first reply, and on a label-driven run "try again" is itself a second manual step. Invalidate-then-ask-for-a-retry is a dead end dressed up as a recovery.
Change
handleAgentTurnFailurenow starts the replacement link immediately after invalidating — in that order, since the reverse would delete the link it just created — and returns its URL. It uses the samependingIdentityLink/identityLinkPendingshape as the first-time link prompt, which arms integration-gateway's existingwaitAndResume, so finishing the link re-runs the interrupted request automatically. One label, one link, no further triggers.The "re-apply the label" / "send your request again" wording (branching on whether the turn has a live channel) survives only as the fallback for when the replacement flow itself can't be started — the credential really is gone at that point, so a retry genuinely will prompt; it just costs another trigger.
Two supporting cleanups:
linkPromptTextfor both the first-time and re-link paths, so they can't drift into describing the same flow differently.startis awaited in atry/catchrather than.catch()on its return value. It's only contractually a promise, and a partialIdentityLinkPort(any test double stubbingstartwith no return) would otherwise crash this recovery path with aTypeError— which is exactly the sort of failure you don't want on the path that handles failures.Also carries the follow-up commit that never made it into #152 (merged before it was pushed): invalidation failures are logged rather than swallowed, and don't promise a retry that can't work.
Verification
92 graph tests pass (709 across
apps+packages), typecheck clean. New cases: the relink URL arrives in the same turn withidentityLinkPendingset and the original request preserved for the resume; the fallback path whenstartfails; and the existing "invalidation itself failed" case.pty-setup-token.test.tsstill can't run locally —node-ptyis absent from this environment and that file is untouched.What this does not fix
The currently stored credential is still unrecoverable — its refresh token was rotated away before any of this shipped, so the first label application after deploying this will hand you a relink URL. Complete it once; from then on each run writes its refreshed credential back (#152) and this shouldn't recur.
🤖 Generated with Claude Code
https://claude.ai/code/session_01KkpJCAfAEi2B3hqfgJhboF