bug: AskUserQuestion multi-question flow crashes Untether with TypeError after answering question 1 of N

[nathanschram]

Summary

Unhandled TypeError in the AskUserQuestion multi-question flow crashes the entire Untether process when the user answers question 1 of N via inline option buttons. systemd auto-restarts in ~10 seconds, but the in-flight Claude session and any other active runs are killed.

Observed live on 2026-05-08 06:43:11 UTC (4:43 PM AEST) on @hetz_lba1_bot running v0.35.2 from PyPI. The bug is unfiled and the same buggy code path exists on the current dev branch (feature/289-loop-scheduler HEAD verified).

Stack trace

File "untether/telegram/loop.py", line 2376, in route_message
    await reply(text=next_msg)        # <-- next_msg is RenderedMessage, not str
File "untether/telegram/bridge.py", line 425, in send_plain
    rendered_text, entities = prepare_telegram(MarkdownParts(header=text))
File "untether/telegram/render.py", line 293, in prepare_telegram
    return render_markdown(assemble_markdown_parts(trimmed))
File "untether/markdown.py", line 31, in assemble_markdown_parts
    return "\n\n".join(
TypeError: sequence item 0: expected str instance, RenderedMessage found

Root cause

src/untether/telegram/loop.py:2362-2376 builds a RenderedMessage for the next question (with HTML parse_mode + inline-keyboard option buttons) then passes it to reply(text=...):

buttons = get_question_option_buttons(flow)
from ..transport import RenderedMessage as _RM

next_msg = _RM(
    text=msg_text,
    extra={
        "parse_mode": "HTML",
        "reply_markup": {"inline_keyboard": buttons},
    },
)
await reply(text=next_msg)  # 💥 reply is bound to send_plain, expects str

reply here is the send_plain partial used for AskUserQuestion confirmations — its text: kwarg is typed str, not RenderedMessage. Passing a RenderedMessage makes markdown.assemble_markdown_parts try to "\n\n".join((rendered_message, body, footer)) which fails.

Impact

• High — crashes the entire Untether process, killing ALL active runs across all chats (not just the one in the multi-question flow).
• systemd Restart=on-failure recovers in ~10s thanks to RestartSec=2 + child cleanup; offset_persistence.py (research: graceful restart improvements — reduce downtime and user impact #287) prevents Telegram update loss. So the visible damage is "your runs got killed and the bot restarted with a startup message" — manageable but bad UX.
• Trigger: any AskUserQuestion call with ≥2 questions where the user answers the first via inline option buttons. Single-question flows are not affected.

Reproduction

1. Send a prompt to a Claude session via Untether that causes Claude to call AskUserQuestion with at least 2 questions, each with options.
2. Answer the first question by clicking an option button.
3. Untether tries to send question 2 with its option buttons → crashes.

The bug only triggers on the rendered code path that includes inline-keyboard buttons for option-based questions. Open-ended (text-reply) questions wouldn't go through this branch.

Why no telemetry caught it earlier

untether-issue-watcher (the local error-log → GitHub issue forwarder) only watches specific named structlog events (handle.worker_failed, handle.runner_failed, etc.). An unhandled exception in route_message propagates up the asyncio task and kills the process before any structured logging can emit, so the watcher misses it. The crash is only visible in the systemd journal as a Rich-formatted Python traceback.

Proposed fix

Replace the reply(text=next_msg) path with a direct transport.send carrying the RenderedMessage and inline keyboard, modelled on the same flow's first-question send helper in commands/ask_question.py:

# src/untether/telegram/loop.py around line 2367-2376
buttons = get_question_option_buttons(flow)
await transport.send(
    channel_id=chat_id,
    message=RenderedMessage(
        text=msg_text,
        extra={
            "parse_mode": "HTML",
            "reply_markup": {"inline_keyboard": buttons},
        },
    ),
    options=SendOptions(
        reply_to=MessageRef(channel_id=chat_id, message_id=user_msg_id),
        thread_id=thread_id,
    ),
)
return

Test coverage

Add a regression test in tests/test_ask_user_question.py that drives a 2-question flow through route_message, asserts the second question is sent successfully, and asserts no exception is raised. Existing tests in this file cover single-question flows and registry lifecycle but do not exercise the multi-question continuation path.

Affected files

• src/untether/telegram/loop.py (lines ~2362-2376)
• tests/test_ask_user_question.py (regression test to add)
• CHANGELOG.md (entry under v0.35.3rc10)

Target

v0.35.3rc10 — should ship in the next staging rc since the bug breaks a user-visible Claude-only feature and is trivially reproducible.

[nathanschram]

Status update — 2026-05-08

Shipped in v0.35.3rc10 (commit e1a7506 via PR #490). Awaiting v0.35.3 stable promotion before close — staging on @hetz_lba1_bot upgraded to rc10 at 08:00 UTC and is running cleanly.

Fix:

• Extracted multi-question continuation logic into module-level helper send_next_ask_question_message in src/untether/telegram/commands/ask_question.py that calls transport.send directly with a proper RenderedMessage (HTML parse_mode + inline_keyboard + reply_to/thread_id SendOptions).
• route_message text-reply path now calls the helper instead of constructing the buggy RenderedMessage and passing it to send_plain (which only accepts str).
• Callback-button continuation path (AskQuestionCommand) unchanged — still edits in place via ctx.executor.edit.

Tests:

• 2 regression tests in tests/test_ask_user_question.py (test_send_next_ask_question_message_uses_rendered_message, test_send_next_ask_question_message_no_thread).
• Full suite: 2629 passed, 82.32% coverage.

[nathanschram]

Additional production occurrence — @hetz_nsd_bot (v0.35.2), 2026-05-09

Confirmed the same TypeError: sequence item 0: expected str instance, RenderedMessage found crashed the nsd VPS Untether (PyPI v0.35.2) twice within 17 minutes on 2026-05-09 (AEST):

Crash	Time (AEST)	Time (UTC)	Chat	AskUserQuestion aq callback (lead-in)
#1	18:15:12	08:15:12	-1003953881142 (nsd-main)	18:14:48, ~24 s before
#2	18:32:01	08:32:01	-1003793725341 (nsd-research)	18:31:43, ~18 s before

Identical traceback as in the issue body — loop.py:2331 → bridge.py:406 → render.py:293 → markdown.py:31 (line numbers shifted vs the original report because v0.35.2 ships a slightly older snapshot than the dev branch). Both crashes:

• Followed an aq callback dispatch in the systemd journal
• Triggered systemd Restart=on-failure (~3 s)
• Killed all active runs in other chats too — Telegram screenshots show ⚠️ interrupted by restart markers in the unrelated nsd-marketing voice-message chat at 18:07 / 18:14 (chat -1003933918343), and on a Question from Claude Code / Type your answer as a reply… pair in nsd-research at 18:31
• Second crash also left a node (Claude Code subprocess) zombie that systemd couldn't kill: Failed to kill control group … Invalid argument / Unit process 8760 (node) remains running after unit stopped

Confirms the impact assessment in the original report ("crashes the entire Untether process, killing ALL active runs across all chats"). The fix in #490 / e1a7506 ships in v0.35.3rc10+; nsd VPS will pick it up at the v0.35.3 PyPI release.

Investigated via the dev session on lba-1; raw evidence retained at /tmp/untether-crash.log on nsd.

[nathanschram]

Closed by 98c018b fix: AskUserQuestion multi-question text-reply path no longer crashes Untether (#488). The text-reply continuation now goes through a new send_next_ask_question_message helper that calls transport.send directly with a RenderedMessage carrying HTML parse_mode + inline_keyboard, instead of the broken send_plain path that passed a RenderedMessage to a text:str kwarg. 2 new regression tests in test_ask_user_question.py. Curated CHANGELOG entry. Shipped in v0.35.3rc10+.