Telegram: retrigger relay failure drops final response after worker completion

[brendandebeasi]

Summary

We’re seeing Telegram turns where the assistant appears to start/finish, but the final full response is not delivered.

Observed behavior

In logs, the sequence is:

1. worker completed, result queued for retrigger
2. retrigger produced text without reply tool, sending as fallback
3. retrigger relay failed, preserving result in history for next turn

So generation succeeds, but delivery fails at retrigger relay. User sees partial output (e.g., opener line) and then nothing.

Expected behavior

If retrigger/fallback text is generated successfully, it should be delivered in the same turn (or user should get an explicit delivery-failed notice).

Related

Possibly adjacent to #258, but this is specifically a delivery failure in retrigger relay, not worker stalling.

Proposed solution (for discussion)

1. Add retry/backoff for retrigger relay send (2–3 attempts).
2. Log transport error details (status code + sanitized response body snippet + adapter/channel context).
3. If retries fail, send a short fallback notice (e.g., "delivery failed; response preserved, send continue to replay").
4. Add regression test: retrigger text generated, first relay send fails, retry/fallback path verified.

[brendandebeasi]

Opened a fix PR for discussion: #582\n\nImplemented in this first pass:\n- Added bounded retry/backoff for outbound relay sends in channel fallback paths\n- Applied retries to retrigger plaintext fallback (the path seen in dropped final replies)\n- Marked when retrigger fallback delivery succeeds\n- Added a short backup user notice if all retrigger relay retries fail (suggests replay)\n\nValidation: passes.\n\nHappy to adjust approach (retry counts, notice text, or fallback behavior) based on maintainer preference.

[brendandebeasi]

Correction (formatting):

Opened a fix PR for discussion: #582

Implemented in this first pass:

• Added bounded retry/backoff for outbound relay sends in channel fallback paths
• Applied retries to retrigger plaintext fallback (the path seen in dropped final replies)
• Marked replied_flag=true when retrigger fallback delivery succeeds
• Added a short backup user notice if all retrigger relay retries fail (suggests continue replay)

Validation: cargo check --all-targets passes.

Happy to adjust approach (retry counts, notice text, or fallback behavior) based on maintainer preference.