…and Wingman confirms it can’t help either.
Yesterday I posted about Analytics accuracy. Today’s issue is more serious: it’s not a measurement gap, it’s data loss with no recovery mechanism.
A custom action (propose_personas) ran successfully in a live session — completed server-side, returned a full valid JSON payload, confirmed via action_runs. The session’s streaming connection back to the browser dropped before the response rendered. The session is now permanently stuck in “pending assistant response” limbo. No error, no retry, no way for the end user to know what happened.
Quoting Wingman: “What happened: The propose_personas action completed successfully server-side at 17:50:48 UTC and returned a valid JSON payload to the Pickaxe runtime. But the runtime’s streaming response back to the browser for session b4ee3c91 dropped before the agent could formulate and stream its reply — likely a connection timeout or transient network issue. The session is now in a “pending assistant response” limbo state.”
I asked Wingman (in the Builder) to diagnose and push the completed response back into that live session. Its own diagnosis, quoted directly:
▎ “There is no Pickaxe API endpoint to inject or replay a message into a live/stuck session. The session is effectively frozen.”
So: a completed, successful action response can be lost mid-delivery, on your own infrastructure, with zero retry logic on the stream and zero recovery path exposed via API — not even for your own support tooling to reach in and fix. The only way out was manually reconstructing the response from action_runs logs outside the product entirely and starting an unrelated new session - ironically, further distorting my Analytics :).
For context, this is the second reliability issue in two days on the same integration (see yesterday’s thread on the env-var/manifest-caching bug — also only fixable by Wingman forcing a manifest redeploy, also not exposed as a normal recoverable operation).
Two straightforward asks:
- Stream delivery needs a retry/resume mechanism, or at minimum a server-side buffer so a completed action response isn’t lost if the client connection blips.
- An API-level way to replay a completed-but-undelivered turn into its session — even just for Wingman/support to use, this shouldn’t require an end user to notice their session died and manually stitch the proposal back together from raw logs.
A session dying silently after doing real, billable work, with no way back in, isn’t an edge case — it’s a basic reliability gap in a product built specifically around long-running agent conversations.