-
Notifications
You must be signed in to change notification settings - Fork 601
Classify RPC errors and recover quietly from Durable Object resets #58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
f7a4a14
Add RPC error classifier for DO resets and connection failures
ndisidore 364d109
Retry idempotent reads once after a Durable Object reset
ndisidore a29aba0
Quiet transient RPC errors and surface chat-send hiccups inline
ndisidore 7d776df
Harden rpcErrors against message drift
ndisidore b2e88a9
Restore e-order by caching the user-DO stub, with reset-safe invalida…
ndisidore 7998195
Simplification pass over the DO-reset resilience work
ndisidore File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,4 @@ | ||
| import { isTransientRpcError, logRpcFailure } from "./rpcErrors"; | ||
| import { | ||
| Fragment, | ||
| memo, | ||
|
|
@@ -1780,6 +1781,7 @@ export const ChatInput = ({ | |
| attachLabel, | ||
| draftUpdateBanner, | ||
| blockedReason, | ||
| chatKey, | ||
| onStop, | ||
| showThinkingTraces = true, | ||
| onToggleThinkingTraces, | ||
|
|
@@ -1825,6 +1827,8 @@ export const ChatInput = ({ | |
| /** When set, the composer is disabled and shows this message — the user must resolve something | ||
| * (e.g. accept/deny a pending connection request) before they can type or send. */ | ||
| blockedReason?: string; | ||
| /** Identity of the chat the composer is bound to; a change clears chat-scoped hints. */ | ||
| chatKey?: number | null; | ||
| onStop?: () => void; | ||
| showThinkingTraces?: boolean; | ||
| onToggleThinkingTraces?: () => void; | ||
|
|
@@ -1838,6 +1842,10 @@ export const ChatInput = ({ | |
| const [capsules, setCapsules] = useState<InputCapsule[]>([]); | ||
| const [pendingAttachments, setPendingAttachments] = useState<PendingAttachment[]>([]); | ||
| const [isSending, setIsSending] = useState(false); | ||
| // The chat the "may not have been sent" hint belongs to; the render condition scopes it, and | ||
| // leaving the chat dismisses it. | ||
| const [sendHiccup, setSendHiccup] = useState<{ chatKey?: number | null } | null>(null); | ||
| useEffect(() => setSendHiccup(null), [chatKey]); | ||
| const [isAttachmentDragActive, setIsAttachmentDragActive] = useState(false); | ||
| const [selectedSlashCommand, setSelectedSlashCommand] = useState<SelectedSlashCommand | null>(null); | ||
| // The caret the slash command picker parses at. Deliberately updated only when it moves to a | ||
|
|
@@ -2276,6 +2284,7 @@ export const ChatInput = ({ | |
|
|
||
| const handleSend = async () => { | ||
| if (sendInFlightRef.current || isSending || isBlocked) return; | ||
| setSendHiccup(null); | ||
| const attachmentsSnapshot = pendingAttachments; | ||
| const readyAttachments = attachmentsSnapshot | ||
| .filter((attachment) => attachment.uploadState === "ready" && attachment.ref) | ||
|
|
@@ -2454,8 +2463,10 @@ export const ChatInput = ({ | |
| }; | ||
|
|
||
| const submitMessage = () => { | ||
| const submittedChatKey = chatKey; | ||
| void handleSend().catch((err) => { | ||
| console.error("Failed to send chat message:", err); | ||
| // The onSend handlers already log; the composer only needs the hint state. | ||
| if (isTransientRpcError(err)) setSendHiccup({ chatKey: submittedChatKey }); | ||
| }); | ||
| }; | ||
|
|
||
|
|
@@ -3050,6 +3061,11 @@ export const ChatInput = ({ | |
| </div> | ||
| )} | ||
| {draftUpdateBanner} | ||
| {sendHiccup && sendHiccup.chatKey === chatKey && ( | ||
| <div className="px-4 pt-2 text-xs text-kumo-warning"> | ||
| Connection hiccup — your message may not have been sent. Check the thread, then try again. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ndisidore what happens in this case?
it looks like the message's body & attachments aren't thrown away, but retrying won't get a fresh User DO stub yet. so when the user tries to resend, will it work? |
||
| </div> | ||
| )} | ||
| {/* Textarea */} | ||
| <div className="relative px-4 pb-1 pt-3"> | ||
| {slashCommandPicker.popup} | ||
|
|
@@ -5213,9 +5229,10 @@ function ChatInterface({ | |
| forceUpdate(); | ||
| } | ||
| } catch (err) { | ||
| console.error("Failed to subscribe to chats:", err); | ||
| reportIssue('chat.subscription-load', err) | ||
| toasts.add({ title: "Unable to load conversations", variant: "error" }); | ||
| if (!logRpcFailure("Failed to subscribe to chats:", err)) { | ||
| reportIssue('chat.subscription-load', err) | ||
| toasts.add({ title: "Unable to load conversations", variant: "error" }); | ||
| } | ||
| } | ||
| }; | ||
|
|
||
|
|
@@ -5366,8 +5383,9 @@ function ChatInterface({ | |
| ); | ||
| } | ||
| } catch (err) { | ||
| console.error("Failed to send message:", err); | ||
| toasts.add({ title: "Failed to send message", variant: "error" }); | ||
| if (!logRpcFailure("Failed to send message:", err, { reportSite: "chat.send" })) { | ||
| toasts.add({ title: "Failed to send message", variant: "error" }); | ||
| } | ||
| throw err; | ||
| } | ||
| }; | ||
|
|
@@ -5388,8 +5406,9 @@ function ChatInterface({ | |
| message, model, capsules, attachments, formats); | ||
| onNavigateToChatRef.current(newChatId); | ||
| } catch (err) { | ||
| console.error("Failed to create new chat:", err); | ||
| toasts.add({ title: "Failed to start conversation", variant: "error" }); | ||
| if (!logRpcFailure("Failed to create new chat:", err, { reportSite: "chat.new" })) { | ||
| toasts.add({ title: "Failed to start conversation", variant: "error" }); | ||
| } | ||
| throw err; | ||
| } | ||
| }; | ||
|
|
@@ -7576,6 +7595,7 @@ function ChatInterface({ | |
| <div className={`flex-shrink-0 bg-kumo-base ${sidebarMode ? "" : "border-t border-kumo-line"}`}> | ||
| <div className={useConstrainedChatWidth ? "mx-auto w-full max-w-[920px]" : ""}> | ||
| <ChatInput | ||
| chatKey={selectedChatId} | ||
| createCapsuleGatekeeper={(accountId, url) => | ||
| overseer.newGatekeeper(accountId, url) | ||
| } | ||
|
|
||
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is likely a controversial decision.
Its driven by https://developers.cloudflare.com/durable-objects/best-practices/error-handling/ specifically the block
When the the user DO resets e.g. storage timeout, overloaded abort (which is exactly what we saw in the logs) that stub is permanently poisoned. Even if we retry it will fail.
This is not super obvious because the premise does hold for the workspace path: Overseer stubs get re-resolved through the namespace on each open, so a retried openGadget genuinely reaches the restarted object. The UserDO path is the only one where a stub is cached across calls.
This should be cheap and safe: namespace.get(id) is not a network call. Stub creation is local and lazy.
Why not just force a re-load? a reload doesn't avoid the retry; it is the retry, multiplied by everything else and makes blast radius wildly disproportionate. It give a worse UX as well as the entire page resets (as opposed to trying to recover silently where possible)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think it should be a problem, but do different stubs mean we lose request ordering to the userDO? i couldn't find any instances were that would be a big problem though, so it seems like a worthwhile tradeoff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha when writing this I told claude "have some pre-canned responses ready for the inevitable push back"
and it had one for e-order! the concern is valid. but practically nothing in our code relies on cross-call ordering through the user stub
preserving ordering while recovering poisoned stubs would require caching and centrally invalidating the stub after native RPC failures across every UserDO operation, adding substantial kernel complexity