Server 0.37.2: prompt queued behind a phantom-busy session is silently dropped (never executed, no trace)

Summary

When a session is in a phantom-busy state (the server reports busy: true / queues new prompts, but no turn is actually running), a prompt submitted via POST /api/v1/sessions/{id}/prompts is accepted with status: "queued" and then silently vanishes: it never executes, never appears in GET /messages, disappears from the queue, and produces no prompt.upsert/error events. From the user's perspective the message was sent and simply disappeared.

Environment

• Server: kimi-code server 0.37.2 (GET /api/v1/meta), macOS, accessed over HTTP API from a third-party client

What we observed (two independent occurrences, both 100% reproducible in the wild)

Case A — session session_05774b9d…:

1. No new messages in history since 05:13 UTC, yet the session was considered busy for hours.
2. 09:11:42 UTC — client POSTs a prompt → {"code":0, "data":{"status":"queued", ...}}, WS prompt.queued event received.
3. The prompt never started. Hours later: GET /sessions/{id}/prompts?status=queued → {"active": null, "queued": []}, and the user message is not in GET /messages (checked page_size=100). Gone without a trace.

Case B — session session_85455226…:

1. Assistant turn completed 09:27:36 UTC. No messages after that.
2. 09:29:22 UTC — client POSTs a 2-char prompt → status: "queued", prompt.queued event received. (So the server still considered the session busy ~2 minutes after the turn ended.)
3. 09:37:37 UTC — the next user prompt runs immediately (session idle again). The 09:29:22 prompt: not in the queue, not in history, never executed.

What works correctly (control experiments on the same server)

• Prompt queued behind a genuinely running turn is promoted and executed when the turn completes naturally. ✓
• Prompt queued behind a running turn is promoted and executed after POST /sessions/{id}:abort. ✓

So the queue mechanism itself is fine — the failure mode is specifically: queued behind a busy state that has no real active prompt underneath. The queued entry then waits forever and is eventually dropped instead of promoted (or dropped when the phantom state is GC'd).

How to detect the phantom state

• GET /api/v1/sessions/{id} → busy: true, main_turn_active: true
• GET /api/v1/sessions/{id}/prompts?status=queued → active: null
• GET /messages shows no activity for minutes/hours

We hit phantom-busy on two different sessions without doing anything exotic (normal prompts from a REST client, occasional :abort, one session had a turn interrupted earlier).

Expected behavior

• A session with no live turn should not report busy: true / queue prompts; and
• a queued prompt should never be silently discarded — it should either execute, or be surfaced with a terminal status (cancelled/failed) via prompt.upsert and the queue endpoint.

Related

• #2817 (prompt sent during an untracked live turn vanishes until the turn ends) — similar symptom, but in our case the message never comes back at all.

Start by tracing POST /api/v1/sessions/{id}/prompts and the session and queue endpoints, comparing the reported busy state with active and queued prompt data. Use the two observed phantom-busy scenarios and related issue #2817 as investigation context. Done means a prompt is executed or receives a terminal status and is surfaced through prompt.upsert and the queue endpoint, without silent loss.