fix(gateway): relay TTS attachments + semantic auto-thread rename on the title turn - #74482
Merged
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Relay TTS attachments + semantic auto-thread rename on the title turn
Two relay-lane bugs from live Discord staging testing (2026-07-29), one PR because both close manual-test findings on the same lane.
1 · TTS audio never attached over relay
Symptom:
text_to_speechsucceeded (tool result carriedmedia_tag), the reply text arrived, but no audio attachment — on any relay platform.Root cause (from fly logs + transcript on the staging box):
_history_media_paths_for_sessionbuilds the delivered-media dedup set from the persisted transcript, excluding only the trailing assistant entry. But the agent persists rows as it produces them — by delivery time the current turn's TTS tool result was already in the transcript, so the fresh TTS path deduped against itself and the attachment was silently stripped. Log signature (exact staging hit, 14:37:50 & 14:40:34):response_delivery_dropped: non-empty response (58 chars) produced no delivered message or attachment … (empty after extract, recovery yielded nothing)— 58 chars = the bareMEDIA:tag.Fix: exclude everything from the last user message onward (the whole current turn) from the dedup set; prior-turn dedup unchanged; no-user-row stores keep the old trailing-assistant fallback. Affects the non-streaming delivery path on every adapter (native + relay) — the streaming path passes explicit history and was unaffected.
2 · Auto-created threads never got the LLM session-title rename
Symptom: initial thread title fine; semantic rename (auto session title → thread name) never happened. Staging telemetry: zero
thread_renameops ever sent.Root cause: the auto-title fires on the first exchange, whose source is the parent-channel event — the thread didn't exist at ingest, so the Phase 4 auto-thread markers can't be present and
_is_discord_auto_thread_lanenever matches on the relay title turn. (Marker path works for turn-2+ events inside the thread — the title turn is exactly the turn it can't cover.)Fix: consume the connector's new send-result feedback (paired NousResearch/gateway-gateway#188 — contract §SendResult
thread_id/auto_thread_name, additive):RelayAdapter.send()caches(thread_id, initial_name)per chat (bounded 256);run.py's title-callback registration + rename lane read it back, passinginitial_nameasonly_if_current_nameso the human-rename-wins guard holds over relay too. Native marker path unchanged; connectors that don't stamp the fields degrade to exactly the old behavior.Tests
test_relay_threads.py+3: feedback capture, absence, bound (relay suite 144 passed)test_history_media_current_turn.py(new, 3): current-turn TTS not deduped · prior-turn still deduped · no-user-row fallbackruff + Windows-footguns clean. No ops flags; no env changes.