refactor(bot): persist Thread/Message state for callback rehydration#3127
Open
refactor(bot): persist Thread/Message state for callback rehydration#3127
Conversation
Store serialized Thread and Message state when creating a bot request and rehydrate them in the cloud-agent session callback handler. This replaces the prior approach of re-fetching the platform message via the adapter, which could fail or lose context when the cloud agent returns. Extracts the SerializedThread/SerializedMessage Zod schemas into a shared message-state module reused by bot-identity.
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Contributor
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Resolved Since Last Review
Other Observations (not in diff)Issues found in unchanged code that cannot receive inline comments:
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Reviewed by gpt-5.5-20260423 · 498,005 tokens |
When `getRehydratedBotRequestMessageState` throws (Redis entry missing, expired, or failed state write), the callback previously only surfaced the error via the outer catch and left the bot_request stuck in pending. Catch the rehydration failure explicitly, capture it to Sentry with targeted tags, and mark the bot_request as error so it does not linger.
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.
Summary
Hardens Thread/Message re-instantiation so cloud-agent callbacks can reliably resume where they left off when the agent comes back. When a bot request is created, the
ThreadandMessageare now serialized via theirtoJSON()shapes and stored in the bot'sStateAdapterkeyed bybotRequestId(24h TTL). The cloud-agent session callback (bot-session-callback/[botRequestId]/route.ts) rehydrates them viaThreadImpl.fromJSON/Message.fromJSONinstead of best-effort re-fetching the original platform message through the adapter — which could fail or lose the author/context entirely.The
SerializedThread/SerializedMessageZod schemas previously inlined inlib/bot-identity.tsare extracted into the newlib/bot/message-state.tsmodule and reused there.Verification
Visual Changes
N/A
Reviewer Notes
bot-request-message-state:prefix; TTL is 24h.processLinkedMessagenow requires astate: StateAdapterargument — both call sites (createKiloBotmention handler and thelink-accountreprocessing path) passbot.getState().getRehydratedBotRequestMessageStatethrows if no entry is found; the callback route relies on the bot request having been created through the new write path. Existing in-flight requests created before deploy will fall through to that error — acceptable given the 24h TTL window.