Repository navigation
feat: support queued scheduled messages with draft preservation and workspace recovery - #51
Conversation
…paths and filenames
…orkspace recovery
|
@codex review |
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. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 86a5e9dda6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| cancelTimedSend(command.terminalId); | ||
| if (timed) scheduleTimedSend(command.terminalId, { at: command.scheduledAt! }); | ||
| if (!timed) cancelTimedSend(command.terminalId); | ||
| if (timed) scheduleTimedSend(command.terminalId, { at: command.scheduledAt!, text: command.text ?? "", images: command.images }); |
There was a problem hiding this comment.
When a phone schedules a timed message while the desktop agent composer already contains an unsent draft, the preceding setDraft/setDraftImages calls replace that draft with the scheduled payload, and this new independent-message path then sends with preserveDraft. The original draft is therefore lost after a pane remount or restart, while the scheduled text remains as the recovered draft. Only completion-triggered schedules should populate the live draft; timed messages should be stored solely in timedMessages.
Useful? React with 👍 / 👎.
| if bytes + size > 200_000 { | ||
| chunks.push(Vec::new()); |
There was a problem hiding this comment.
For a valid large library this loop can create far more than eight parts, including the 200-part case covered by the new Rust test. The relay's inline endpoint returns only eight payloads and sets hasMore, but Android's RelayClient.pendingMessages ignores that flag and fetches only one batch per recovery pass; because all part notifications also share one FCM collapse key, a complete library can take dozens of three-second foreground polling cycles to commit even though every part is already stored. The receiver should immediately drain hasMore batches, or the transfer must be bounded to what one recovery request can retrieve.
Useful? React with 👍 / 👎.
Summary