pi agent (json mode, default config): turn-end not detected after assistant reply — session stuck busy, no "turn complete" until /stop

Summary 摘要: With pi agent in RPC mode, some turns never produce a turn complete log line even though the assistant's final reply has already been streamed to the IM. The cc-connect session stays in "busy" state indefinitely; subsequent user messages are logged as message queued for busy session and never delivered. Only /stop recovers (killing the pi process). Reproduced twice within ~17 minutes on a fresh install.

Possibly related to #1659 (pi 0.84.0 RPC protocol change): that fix covered toolcall_end, but other events on the delta-only protocol (turn end / agent_end / willRetry) may have the same blind spot.

Environment

• cc-connect: v1.5.0 (npm, commit 17c61062)
• pi: 0.85.1 (@earendil-works/pi-coding-agent)
• Platform: Feishu (WebSocket), rpc = true, mode = "default"
• OS: Linux

Reproduction

1. Send a message that triggers a normal multi-tool turn → usually completes fine (see "good turn" below).
2. Occasionally a turn finishes from the user's perspective (full reply visible in Feishu) but the engine never logs turn complete.
3. Send any follow-up message → message queued for busy session ... queue_depth=1, never delivered.
4. /stop → piSession: process error ... signal: killed, next message spawns a fresh session and works.

Log excerpts (INFO level)

Stuck turn #1 (17:50) — no turn complete for 5m45s, reply already visible in Feishu:

17:50:19 INFO "message received" platform=feishu content_len=139
17:50:19 INFO "processing message" session=s3
17:50:19 INFO "session spawned" agent_session="" is_resume=false
17:55:53 INFO "message received" content_len=172
17:55:53 INFO "message queued for busy session" queue_depth=1      ← pi already replied, still "busy"
17:56:04 INFO "audit: command_executed" command=stop               ← manual recovery
17:56:04 WARN "slow agent send" elapsed=5m44.776s
17:56:05 ERROR "piSession: process error" cmd=pi error="signal: killed"

Good turn right after (17:56) — for contrast, turn complete appears:

17:56:09 INFO "processing message" session=s3
17:56:42 INFO "turn complete" agent_session=01a0aecb-... tools=2 response_len=1557 turn_duration=32.9s

Stuck turn #2 (18:03) — identical pattern:

18:03:08 INFO "processing message" session=s3 content_len=308
18:07:00 INFO "message queued for busy session" queue_depth=1      ← no turn complete in between
18:07:21 INFO "audit: command_executed" command=stop
18:07:21 WARN "slow agent send" elapsed=4m12.65s
18:07:22 ERROR "piSession: process error" cmd=pi error="signal: killed"

Observations

• Both stuck turns show zero log output between "session spawned"/"processing message" and the eventual /stop — no tool events, no error, no turn complete. The reply text itself WAS delivered to Feishu, so message deltas flowed; only the turn-end signal was lost (or never emitted).
• input_tokens=0 output_tokens=0 on the good turn suggests usage reporting may also be affected on this protocol version, though the turn itself completed.
• Workaround in place: idle_timeout_mins / max_turn_time_mins as a safety net; /stop for manual recovery.

Expected behavior

A finished pi turn should always be detected and logged as turn complete, releasing the busy session — including on pi ≥ 0.84.0's delta-only message_update protocol.

Happy to re-run with debug-level logs if that helps pinpoint which RPC event is being missed.