In-flight turn teardown broken — a still-running turn cancels the NEXT turn at t=0 (globally, even across threads)
Evidence
- g7-28 "think step by step … growth plan":
ready → inference_start → iteration_start@0.1s, then the channel_web_chat RPC returned an error and the turn was killed at t=0.1s — same signature as a "Cancelled by newer request" — because a prior turn was still in flight server-side (a manual recall turn just before it).
- g7-28 isolated re-run (no other turn in flight): ran 160s normally → CONFIRMS the 0.1s death was cross-turn interference, NOT prompt-specific.
- g6-26 (same-thread, right after g6-25 client-timed-out at 299.8s): immediate
chat_error {error_type: cancelled, "Cancelled by newer request"} at t=0 — never executed.
Ask
A client giving up (timeout) must cleanly cancel its own server turn, and a new request must not be killed by a prior in-flight turn. Currently a still-running turn causes the next turn (even on a different thread) to be cancelled at start — cancellation isn't scoped to the old request_id, and in-flight turns aren't torn down before the next begins. Check the channel/web-chat turn lifecycle + cancellation routing (openhuman channels/providers/web and/or the tinyagents agent-loop cancellation). Real-user impact: a slow turn makes the user's next message silently die.
In-flight turn teardown broken — a still-running turn cancels the NEXT turn at t=0 (globally, even across threads)
Evidence
ready → inference_start → iteration_start@0.1s, then thechannel_web_chatRPC returned an error and the turn was killed at t=0.1s — same signature as a "Cancelled by newer request" — because a prior turn was still in flight server-side (a manual recall turn just before it).chat_error {error_type: cancelled, "Cancelled by newer request"}at t=0 — never executed.Ask
A client giving up (timeout) must cleanly cancel its own server turn, and a new request must not be killed by a prior in-flight turn. Currently a still-running turn causes the next turn (even on a different thread) to be cancelled at start — cancellation isn't scoped to the old
request_id, and in-flight turns aren't torn down before the next begins. Check the channel/web-chat turn lifecycle + cancellation routing (openhumanchannels/providers/weband/or the tinyagents agent-loop cancellation). Real-user impact: a slow turn makes the user's next message silently die.