[Bug]: In-flight turn silently dropped when the V2 Agent cutover migration restarts the local runtime #536

Product or interface

Desktop app

Version

3.1.4 (Windows desktop build; com.minimax.agent.cn 3.1.4)

Platform

Windows

OS version and architecture

Windows 11 x64 (10.0.26300)

Issue area

Agent stuck / slow / repeated loop

Steps to reproduce

1. Run a long agent turn in the Desktop app (one with many tool calls).
2. While the turn is still in flight - between a tool result and the next model response - let the app perform its V2 Agent cutover migration, which restarts the local runtime process.
3. Observe the turn.

The migration is visible in the hourly runtime log (~/.minimax/.minimax/v2/observability/logs/runtime-YYYYMMDDHH.log):

[09:49:59.477] V2 Agent cutover {"migration_id":"agent-cutover-1792806599474","phase":"target_preflight","status":"completed", ...}
[09:49:59.509] V2 Agent cutover {"migration_id":"agent-cutover-1792806599474","phase":"owner_create","status":"completed", ...}
[09:50:02.503] sandbox.state_observed {"runtime_instance_id":"<NEW-ID>", ...}
[09:50:03.435] local-runtime-v2 startup timings {"outcome":"ready","total_ms":4652, ...}

The runtime_instance_id changes across the restart, and the app process is replaced at the same moment.

Expected and actual behavior

Expected: an in-flight turn that is interrupted by a runtime restart should either be resumed automatically, or be surfaced to the user as an interrupted turn with an explicit reason (and ideally a retry affordance).

Actual: the in-flight turn is silently dropped. The session history ends on a toolResult with no closing assistant message, no error is surfaced in the UI, and no error is written to the runtime log. The next user message starts a brand new turn (execution_mode: activate) with no indication that the previous work was lost.

Redacted error summary

Runtime log excerpt, one hour file, all paths and content redacted. Session/turn ids are the local runtime's own random ids, kept so the log can be located:

[09:45:46.471] permission.enforcement {"session_id":"<SID-A>","turn_id":"<TID-1>","tool_call_id":"chatcmpl-tool-9138222eed08c999","tool_name":"edit","policy_behavior":"allow","gate_result":"proceed", ...}
[09:45:51.935] llm_response_identifiers {"session_id":"<SID-A>","turn_id":"<TID-1>","provider":"minimax","model":"MiniMax-M3.1-Flash","response_status":200, ...}
                              <-- no further entries for <SID-A> / <TID-1> until the next user message
[09:49:59.477] V2 Agent cutover {"migration_id":"agent-cutover-1792806599474","phase":"target_preflight","status":"completed", ...}
[09:50:02.503] sandbox.state_observed {"runtime_instance_id":"<NEW-ID>", ...}
[09:50:03.435] local-runtime-v2 startup timings {"outcome":"ready","total_ms":4652, ...}
[10:12:59.566] http GET /minimax-desktop/api/v1/session/<SID-A>/input-summaries status=200
[10:13:00.875] http GET /minimax-desktop/api/v1/session/<SID-A>/turn-continuation status=200
                              <-- turn-continuation answered, but the turn was NOT resumed
[10:13:58.446] [local-runtime-v2] agent turn setup stage started {"session_id":"<SID-A>","turn_id":"<TID-2>","execution_mode":"activate", ...}

Additional observations that narrow this down:

• The model API was healthy right up to the cut: response_status: 200 on the last request at 09:45:51.
• No runaway-guard intervention is recorded for this turn. (runaway_guard_turn_summary exists in the same log for other sessions, with signals all zero and reminder_injected: false - i.e. that guard is only a turn-end marker, it did not stop this turn.)
• The runtime process itself did not log an error, abort or crash entry.
• A second, concurrently running session (<SID-B>) was interrupted by the same restart and was resumed correctly at 10:12:53 with execution_mode: "continuation" (14 agent turn setup stage entries with execution_mode: continuation). So a resume path exists, but it was not applied to <SID-A>; the desktop app asked turn-continuation for it and the answer was "do not continue".

This is the second time the same symptom has been observed on this machine (the previous occurrence also ended on a toolResult with no closing assistant message), so it is reproducible rather than a one-off.

Screenshots

N/A - the symptom is silent (no on-screen error).

Before submitting

• I have searched existing issues.
• I have included my version and removed sensitive information.