Repository navigation
style(chat): drop the reply fill, spread left-hand messages; fix queued recall - #160
Conversation
With no outline and no side padding, the card background was the only thing left boxing a reply in. Replies now sit on the chat background; user messages keep their tinted bubble on the right.
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. |
A queued message is a draft waiting under the input, not a sent bubble, so it now fills the row like an agent follow-up instead of shrinking to its text.
A cron or message wake stayed a text-sized row, so it read narrower than the agent follow-ups and queued messages around it. Every left-hand message now fills the row; only the user's own bubble sizes to its text.
The file items sit straight in the command list with no group around them, so the first one touched the search input. The list now has the padding a group would give it.
Recalling deleted the log row before the attachment rows that reference it, so with foreign keys on, editing a queued message with an image failed with a 500. The attachment rows now go first, in one transaction with the log row.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4df557f0e7
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Hard delete the pending row (it was never processed by AI). Its attachment | ||
| // records reference it, so they go first. | ||
| db.transaction((tx) => { | ||
| tx.delete(attachmentsTable).where(eq(attachmentsTable.logId, pending.id)).run() |
There was a problem hiding this comment.
Preserve attachments when recalling a queued message
When a user edits a queued message containing attachments, this deletes the attachment records before returning their metadata, so the returned IDs immediately resolve to 404. The only caller, ChatBody.handleEditPending, restores result.content but ignores result.attachments, meaning resending the edited message silently drops every attachment and leaves their files orphaned on disk. Keep the attachments usable through the edit flow or explicitly restore them into the input before deleting their records.
Useful? React with 👍 / 👎.
Recalling a queued message deletes its attachment records, and the input only got the text back, so resending dropped every attachment. Download the attachments before deleting the message and put them back into the input with the text; a failed download leaves the message queued.
Summary
assistanttone inchat-block.ts.UserMessageEntryinLogEntry.tsx).DiffPanel.tsxnow hasp-1.deletePendingMessage()deleted the log row before the attachment rows that reference it, which fails with foreign keys on. Attachments now go first, in one transaction with the log row.mainis merged in, since the queued-message layout only exists there.Test plan
chat-blocksandassistant-message-actionstests: replies have nobg-class; queued messages and cron wakes arew-full, notw-fitpending-messages-unittest recalls a queued message with an attachment (failed withFOREIGN KEY constraint failedbefore the fix)