Part of #86647.
During the #79278 persistent-mute investigation the decisive evidence was
an absence: a Desktop request left no INFO record in agent.log OR
gateway.log ("832 platform=webhook, 194 platform=telegram, 0
platform=desktop"), so the muted 13:15-13:19 window — 12 non-idempotent
Qdrant snapshots, zero results returned — was structurally
indistinguishable from a request that never arrived. The issue calls out
fixing this observability gap as the first actionable step.
This adds the two INFO records to _run_prompt_submit, the single choke
point every Desktop/TUI turn passes through (user submits, queued
prompts, auto-continue, goal follow-ups, watch upgrades):
- "tui prompt accepted": emitted before the turn thread starts, carrying
the UI session id, the gateway session_key, and the agent's live
session_id — the id triple a rotation-mute trace needs, since
compression rotates agent.session_id independently of the other two.
No prompt content is logged (length only).
- "tui turn finished": emitted in the turn's finally on every path
(success, returned error, exception, interrupt), re-reading
agent.session_id so a mid-turn compression rotation shows up as an
accepted/finished pair with different agent ids. A missing finished
record now positively identifies a turn thread that died before its
finally.
Placement follows @Adolanium's note on the issue: in _run_prompt_submit,
logging sid + session_key + agent.session_id, NOT another platform= line
in gateway.log (Desktop does not use the messaging gateway).
tui_gateway is under COMPONENT_PREFIXES["gui"], so the records land in
agent.log (root catch-all) and gui.log when running under the dashboard.
Tests (tests/tui_gateway/test_prompt_accept_logging.py): accepted+finished
pair on success with the full id triple and no prompt content leaked;
mid-turn rotation visible as differing agent ids across the pair;
finished record fires on the exception path and the returned-error path.
Sabotage-verified: removing the accepted record fails the suite.
Teknium
be083358b2