Carry the reply prefill's subject onto every reply - #370
Conversation
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. |
There was a problem hiding this comment.
Pull request overview
Carries reply subjects through CLI and TUI reply paths, preventing drafts from appearing as “No subject.”
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Changes:
- Preserves server-prefilled subjects with local fallback derivation.
- Sends subjects for replies and reply drafts across CLI and TUI.
- Updates the SDK dependency, MCP model snapshot, and tests.
Reviewed changes
Copilot reviewed 10 out of 11 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
go.mod |
Pins the subject-capable SDK revision. |
go.sum |
Updates SDK checksums. |
nix/package.nix |
Updates the vendored dependency hash. |
internal/cmd/thread_reply.go |
Resolves and derives reply subjects. |
internal/cmd/thread_reply_test.go |
Tests prefilled, derived, and transmitted subjects. |
internal/cmd/reply.go |
Sends subjects through reply operations. |
internal/cmd/compose.go |
Sends subjects for thread replies. |
internal/tui/compose.go |
Carries hidden reply subjects through TUI forms. |
internal/tui/compose_test.go |
Verifies TUI subject loading and transmission. |
internal/mcpserver/model/openapi.json |
Adds reply subjects to the vendored API model. |
internal/mcpserver/model/PROVENANCE.json |
Records the corresponding SDK revision. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
@codex review |
![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: 2c5fa27fc2
ℹ️ 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".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5dca3e7062
ℹ️ 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".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1a6ea8eba3
ℹ️ 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".
|
@codex review |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
4c7d65d to
8e23614
Compare
hey reply read the prefill from GET /entries/{id}/replies/new.json but
kept only the recipients, and the SDK's ReplyMessagePayload had nowhere
to put a subject anyway — so every reply draft saved as "No subject" in
HEY's Drafts (hey-cli#341, part 1 of 3). HEY never derives a reply's
subject server-side.
Bump hey-sdk to the release that models subject on ReplyMessagePayload,
and pass it through everywhere a reply goes out:
- resolveThreadReply keeps the prefill's "Re: …" subject on the target,
and the local fallback derives one from the entry's subject the way
HEY does in Entry::Replyable#reply_subject — a "Re: " prefix without
doubling one already there.
- hey reply and hey compose --thread-id send it on both the draft and
the delivery paths.
- The TUI reply form carries it invisibly: the form still shows no
subject field, matching HEY's own reply composer.
Reply content is untouched: the server appends the quoted original at
delivery via auto_quoting, so the prefill's quoted body still must not
be echoed back.
The reply-subject branch moved (README example and an apidiff acknowledgment), so the pseudo-version, the vendored model provenance, and the vendorHash all follow.
hey-sdk#134 landed, so the pin moves from the branch pseudo-version to the merge commit's; provenance and vendorHash follow. Flips to the release tag when one is cut.
The TUI synthesized a reply's subject and recipients locally from the entry, so it never saw what only HEY knows: the acting user's own addresses, aliases and catch-alls to leave off the recipient lines, and the prefilled "Re: …" subject itself. Ask the reply prefill first and keep the local computation as the fallback for a failed read or the empty answer a thread with yourself produces — the same contract resolveThreadReply already holds.
A recipientless prefill — a thread with yourself — still carries the subject HEY computed, and both reply paths were discarding it to re-derive one from the message, whose subject is optional and can be absent. Only the recipients needed the local computation; the subject survives the fallback, in resolveThreadReply and the TUI's reply context alike.
The recipients bullet still described the local-only computation and an SDK without NewReply; both reply paths now start from HEY's prefill with the local computation as fallback.
8e23614 to
3b0e8a9
Compare
hey replyread the reply prefill (GET /entries/{id}/replies/new.json) but kept only the recipients — and the SDK'sReplyMessagePayloadhad nowhere to put a subject anyway. HEY never derives a reply's subject server-side, so every reply draft saved as "No subject" in HEY's Drafts. This is the subject leg (part 1 of 3) of #341.Built on basecamp/hey-sdk#134 (merged), which models
subjectonReplyMessagePayloadand takes it inCreateReply/CreateReplyDraft.go.modpins the merge commit's pseudo-version (v0.28.2-0.20260831223614-ed5cf6fadf55); the pin flips to the release tag when one is cut. The vendored MCP model snapshot and its provenance are synced to the same commit, perTestCatalogModelProvenance.Change
resolveThreadReplykeeps the prefill's"Re: …"subject on the target (replyPrefillFromServer, formerlyreplyRecipientsFromServer). The local fallback derives one from the entry's subject the way HEY does inEntry::Replyable#reply_subject— a"Re: "prefix without doubling one already there, in any casing.hey replyandhey compose --thread-idsend it on both the draft and delivery paths.auto_quotingdefaults on), so the prefill's quoted body still must not be echoed back — sending it would double-quote.Tests
resolveThreadReplyasserts the subject on the target from both the prefill and the fallback; the reply-draft test asserts the wire carriesmessage[subject](the bug's exact symptom);replySubjectderivation table incl.Re:normalization.make checkgreen.Basecamp: A reply can't carry a subject — every reply draft saves as "No subject"
Summary by cubic
Carries the reply prefill's
"Re: …"subject onto every reply —hey reply,hey compose --thread-id, and the TUI reply form — so reply drafts no longer save as "No subject" in HEY's Drafts (part 1 of 3 for #341). The TUI reply form now also reads its recipients from the prefill, like the CLI already did, and the subject survives even when the prefill answers no recipients.github.com/basecamp/hey-sdk/goto a pseudo-version on merged mainline, syncing the vendored MCP model snapshot; flips to the release tag once one is cut.Written for commit 3b0e8a9. Summary will update on new commits.