fix: preserve steered audio for inbound TTS#95596
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 6, 2026, 11:31 PM ET / 03:31 UTC. Summary PR surface: Source +28, Tests +109. Total +137 across 12 files. Reproducibility: yes. source inspection gives a high-confidence reproduction path: a text-originated active run can accept an audio follow-up, but current main does not carry that audio fact into final TTS dispatch. I did not run a live WhatsApp timing repro in this read-only review. Review metrics: 2 noteworthy metrics.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Rebase and adapt the operation-local marker to current main’s queue option shape, then land it as the canonical fix if merge-head validation and any maintainer-required WhatsApp proof pass. Do we have a high-confidence way to reproduce the issue? Yes, source inspection gives a high-confidence reproduction path: a text-originated active run can accept an audio follow-up, but current main does not carry that audio fact into final TTS dispatch. I did not run a live WhatsApp timing repro in this read-only review. Is this the best way to solve the issue? Yes, the operation-local marker remains the narrowest maintainable fix shape because the audio fact belongs to the accepted reply operation, not persisted session state. The branch still needs rebase/adaptation before it can be merged on current main. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 118e5bd76223. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +28, Tests +109. Total +137 across 12 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
aaafe08 to
b0561e4
Compare
|
Does this change affect the behavior of config in any way? |
b0561e4 to
1a96d26
Compare
Co-authored-by: Marcus Castro <[email protected]>
1a96d26 to
30eabab
Compare
|
Maintainer prep complete for
Known proof gap: no separate credentialed WhatsApp roundtrip was available; the contributor issue reproduction plus dispatch/message-tool regression coverage exercises the affected ownership paths. |
|
Merged via squash.
|
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
What Problem This Solves
When
tts.autois set to"inbound", OpenClaw should use voice output for replies that answer inbound audio. A text-started reply run could later accept steered inbound audio while the active run was still streaming, but TTS delivery kept the original text message's audio classification. The agent could therefore answer the later audio with a text-only reply.Fixes #76831.
Why This Change Was Made
The accepted-audio fact belongs to the current reply operation, not durable session state. This rewrite latches that fact on
ReplyOperationonly after the active run accepts the steer. Automatic final, block, and tool delivery reads it at TTS time; embedded message tools receive a dynamic getter somessage_tool_onlydelivery reads the same current operation state.That leaves one canonical owner, avoids persisted session compatibility, removes the original embedded-queue option threading, and keeps the behavior channel-agnostic.
User Impact
Users with
tts.auto: "inbound"receive voice output when a later inbound audio message is accepted into an active text-originated run, including configurations that deliver replies through the message tool.Rejected steers, later text messages, and unrelated reply operations do not change delivery modality.
Evidence
30eababa41dpnpm test src/auto-reply/reply/agent-runner.media-paths.test.ts src/auto-reply/reply/dispatch-from-config.test.ts src/agents/tools/message-tool.test.ts: 382 tests passedpnpm check:changed: core/test typechecks, every core lint shard, and runtime guards passed in 10m03sgit diff --check