createTurn cancels the in-flight turn before validating the new request — a duplicate approval submission can truncate the approved turn mid-stream #508

Activity

1. MachineLearning-Nerd commented on Aug 30, 2026

   

   MachineLearning-Nerd

   on Aug 30, 2026

   Author

   More actions

   Reproduced this end to end against a fresh local 0.1.4 server, with a different model provider than the original report, so it is not model specific.

   Sequence:

   1. Run a mission until the turn pauses on a tool listed in require_approval_for_tools.
   2. Send the approval as a new turn (user.tool_approval input). The approval turn starts, the gated tool executes, and its tool.response streams back.
   3. ~30ms after the tool response, send the exact same approval input again, simulating a double click on Approve.

   Result:

   • The duplicate request is correctly rejected with 422 and no new turn is created (the session still has exactly 2 turns):

     Status code: 422
     {"error":{"message":"thread main: messages[0] no pending approval for tool_call_id 'call_00_YVVj2FqshNnqrLTIzfHo2622'"}}
     

   • The running approval turn is cancelled anyway, timestamped 2ms after the duplicate arrived, before the model produced any post-tool output:

     {"status":"cancelled","reason":"cancelled-for-next-turn","completedAt":"2026-08-30T17:04:20.509Z"}
     

   So a request the server itself rejects as invalid still destroys the in-flight turn. The gated tool's side effect had already executed by then; everything after it (the model's message relaying the result, any follow-up tool calls) is lost.

   repro script (Node, uses @truefoundry/trueforge-sdk)

   import { TrueForge } from "@truefoundry/trueforge-sdk";
   
   const baseUrl = "http://localhost:8891";
   const client = new TrueForge({ baseUrl, timeoutInSeconds: 300 });
   
   // any registered agent with one tool in require_approval_for_tools
   const session = (await client.sessions.create({ agent: { name: "my-agent" } })).data;
   
   let approvalCall = null;
   const stream1 = await client.sessions.createTurnStream(session.id, {
     input: [{ type: "user.message", content: "<mission that ends in the approval-gated tool>" }],
   });
   for await (const item of stream1.withMetadata()) {
     const ev = item.data;
     if (ev.type === "tool.approval_required") {
       approvalCall = { threadId: ev.threadId, toolCallId: ev.toolCalls[0].id };
     }
   }
   
   const approvalInput = [{
     type: "user.tool_approval",
     threadId: approvalCall.threadId,
     toolCallId: approvalCall.toolCallId,
     approval: { status: "allow" },
   }];
   
   let fired = false;
   const stream2 = await client.sessions.createTurnStream(session.id, { input: approvalInput });
   for await (const item of stream2.withMetadata()) {
     const ev = item.data;
     if (ev.type === "tool.response" && !fired) {
       fired = true;
       // duplicate approval while the approval turn is still streaming
       client.sessions.createTurnStream(session.id, { input: approvalInput })
         .then(async (s) => { for await (const it of s.withMetadata()) {} })
         .catch((e) => console.log("duplicate rejected:", e?.message));
     }
     if (ev.type === "turn.done") console.log("approval turn state:", JSON.stringify(ev.state));
   }
   
   const turns = (await client.sessions.listTurns(session.id)).data;
   console.log("turn count:", turns.length);

   The cause matches what the issue describes: SessionHandle.createTurn freezes the previous turn with cancelled-for-next-turn before the new request's input is validated, and there is no rollback when validation then fails.
2. debajyoti-truefoundry commented on Aug 31, 2026

   

   debajyoti-truefoundry

   on Aug 31, 2026

   Contributor

   More actions

   @MachineLearning-Nerd

   ~30ms after the tool response, send the exact same approval input again

   Is this something that is possible from the TrueForge UI today?
3. MachineLearning-Nerd commented on Aug 31, 2026

   

   MachineLearning-Nerd

   on Aug 31, 2026

   Last edited by MachineLearning-Nerd

   Author

   More actions

   Yes. This can happen from the bundled TrueForge UI today, although it requires a timing race such as clicking Approve twice. In @truefoundry/trueforge-ui@0.2.4, the approval controls remain enabled while the approval turn is still running. A second click can submit the same user.tool_approval input. The server returns HTTP 422 and creates no new turn for the duplicate, but the request can still cancel the in-flight approval turn, as demonstrated in this issue. The UI should disable the controls immediately after the first click. The server should also validate and persist the new turn before freezing the previous one.
4. dajiaohuang commented on Sep 4, 2026

   

   dajiaohuang

   on Sep 4, 2026

   More actions

   I verified that current main still freezes the previous turn before validating a new approval/tool-response resume. I prepared a tested fork-only Draft PR at dajiaohuang#1. It adds a read-only running-turn guard, preserves user-message barge-in behavior, and includes regression coverage.

   Validation passed for the focused session suite (12 tests), core typecheck, Prettier, and ESLint. The full core suite had 403 passing tests and one unrelated pre-existing Windows path-separator assertion failure in tests/core/sandbox/Sandbox.paths.test.ts.

   Because the contribution policy requires maintainer approval before community code contributions are submitted upstream, I did not open an upstream PR. If this direction fits the project, please grant the required invitation/approval for an upstream contribution.