Repository navigation
fix(mobile): keep a send rejected with 409 or 426 retryable - #1968
Conversation
The mobile outbox marks any 4xx other than 408, 425 and 429 as refused, and a refused send can't be retried. Two of those rejections clear on their own. threads/send answers 409 "Stop teaching first" while the bot is in a teaching session, and the API answers 426 when the app is older than RAKAZO_MIN_CLIENT_BUILD (elie222#1849). After teaching stops, or after the update the app itself offers, the same send would succeed, but the message stays "Not sent" with no way to resend it. Both now fail as retryable: "Not sent · Tap to retry" and Try Again. Other client rejections stay refused. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
 [Medium impact] This PR appears safe to merge. SummaryMobile sends rejected with 409 or 426 now remain available for manual retry instead of becoming permanently refused.
Reviews (1) · Last reviewed commit: "fix(mobile): keep a send rejected with 4..." · Reviewed by Greptile |
Playwright screenshotsNo new feature frames; gallery is suite-vs-main drift. Open screenshot gallery · Dashboard · CI run Updated for commit |
Why
The mobile outbox marks any 4xx other than 408, 425 and 429 as refused. A refused send shows "Not sent" and can't be retried. #1778 made one of those, the missing-model error, retryable once a model is connected. Two more rejections clear on their own:
threads/sendanswers this while the bot is in a teaching session, for example one started on desktop while the user writes from the phone. Once teaching stops, the same send would go through, but the message stays "Not sent".RAKAZO_MIN_CLIENT_BUILD, and the app offers an over-the-air update or the store. The unsent message is saved to disk as refused, so after the update it comes back with no way to resend it.What changed
sendWaitingMessagesinthread-feedback.tstreats 409 and 426 like 408, 425 and 429: the send fails as retryable ("Not sent · Tap to retry", Try Again in the long-press menu) and resends with the same client nonce. Nothing resends automatically. Every other client rejection stays refused, and the "keeps unrelated client rejections refused" test is unchanged.Consent conflicts that reach the outbox wrapped in
AiConsentBlockedwere already retryable (acc401f). This covers a 409 that comes straight from the server.Known residual: a 426 that a build without this fix already saved as refused stays refused after the update. The saved entry keeps only the error text, not the status, so restoring it as retryable would mean matching on copy.
No UI copy, server, or web changes.
How I tested
thread-feedback.test.tsx, run for 409 and 426: a send rejected with that status shows "Not sent · Tap to retry", the tap calls retry, and a manual resend is accepted. Both cases fail on main (Expected: "failed",Received: "refused") and pass with the fix.pnpm checkandpnpm lintshow the same results before and after the change, apart from the two new passing tests.🤖 Generated with Claude Code