Conversation
…eduled sends The reply anchor rode in a shared Arc<Mutex<Option<i64>>> slot on Ctx: concurrent worker turns could overwrite each other's anchor mid-delivery, and scheduled/proactive sends inherited whatever anchor the last interactive job left behind. Thread the anchor as a parameter from the job through the delivery chain instead. Scheduled sends pass None and are never anchored; approval confirmations anchor to the message they answer; schedule questions, primary delivery, and other system replies are unanchored. Adds a payload test asserting reply_parameters is present only when anchored, with allow_sending_without_reply set.
Telegram updates carry reply_to_message when the user replies to a specific message; the gateway dropped it at parse time, so the backend saw only the bare reply text with no linkage. Capture the replied-to message as a flattened one-line excerpt (200 char cap) on RawMessage.reply_context and prefix it to the backend prompt as a blockquote. The quote is context only: approval answer matching and the /stop check still see the raw user text, so replying "/stop" to an old message still stops the run. iMessage and Slack set reply_context: None.
When the user selects a specific portion of a message and replies, Telegram sends the selection in message.quote. Use it for the backend excerpt when present; fall back to the full replied-to message text.
bkuri
changed the title
added 2 commits
September 17, 2026 19:08
A backend reply may start with a '> quoted portion' line; the gateway lifts it into reply_parameters.quote (1024-char cap, API limit), strips it from the displayed text, and it renders in the Telegram reply header when the message is anchored. Quote-only replies are left untouched so they cannot become empty messages. System and scheduled sends never quote.
…skill The '> quoted portion' convention ships in the managed skill so every assistant learns it when push init refreshes the skill (managed version bumped to 4 to trigger the refresh on upgrade).
bkuri
marked this pull request as ready for review
September 18, 2026 04:11
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…ss rich fallback Greptile review follow-ups: - The backend run completion path recorded out.reply and delivered with no lifted quote, so the '> quoted portion' convention never fired for the one reply type that carries it. Lift before recording and thread the quote through deliver_stored. - The rich-to-plain fallback in send_rich_reply dropped the reply anchor and quote; pass them through to send_plain_reply. - Drop the now-unused send_rich/send_plain wrappers. - FakeRunner gains an optional reply override; new gateway test asserts a leading quote line is stripped from the delivered reply.
Non-Telegram channels never render the extracted quote, so lifting a leading '> quoted' line from a backend reply there silently dropped it from the user's message. Gate the lift on the channel; Slack and iMessage keep the blockquote line as ordinary formatting.
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.
What
Bidirectional reply threading for Telegram.
Outbound: bot replies anchor to the triggering message via
reply_parameters: {message_id, allow_sending_without_reply: true}, so replies still deliver if the trigger message was deleted. Multi-chunk replies all anchor. Scheduled/proactive sends are never anchored. Other channels unaffected. A backend reply may also start with a> quoted portionline — the gateway lifts it intoreply_parameters.quoteso the reply header highlights exactly the part being answered (one quote per message: API limit). The convention ships in the managed push skill (version bumped to 4 sopush initrefreshes it).Inbound: when the user replies to a specific message, the backend prompt gets a flattened one-line excerpt of it (200-char cap) as a blockquote — preferring the user's text selection (
quote) over the full message when they selected a portion. Approval matching and/stopstill see the raw user text, so replying/stopto an old message still stops the run.Resume-after-restart deliveries send unanchored rather than wrongly anchored.
Test plan
cargo test: 486 passed, 0 failed./stopon reply.