Approved HITL tool's execution result missing from history — "tool_use ids were found without tool_result blocks"

[edoardorinaldi]

eve version

eve@0.17.1

Node.js version

v24.18.0

Where does the bug occur?

• Production (eve start / deployed, on Vercel)

Describe the bug

An approval-gated (approval: once()) authored tool with a real execute sometimes has its side effect run successfully, but the resulting tool_result never makes it into session history before the harness sends the next model call — leaving that tool_use id dangling. The next request to Anthropic is rejected with:

messages.10: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_01KM8aeG4pT8SNYub2Cbgj4Q. Each `tool_use` block must have a corresponding `tool_result` block in the next message.

This is not a one-off: it reproduced twice independently, in the same app, on two different turns of two different conversations, always with the same shape:

1. The model calls an approval-gated tool (hubspot_create_object, approval: once(), with a real async execute that PATCHes/POSTs to an external API).
2. The user approves the tool call (Responded: Yes in the UI).
3. The tool's real side effect completes — confirmed both times by checking the external system directly (a HubSpot company record was created both times, with the exact properties from the approved call's input).
4. A second call to the same tool name (a different object, e.g. a HubSpot deal or contact — auto-approved via once()'s "already approved this session" logic) completes and renders normally in the UI.
5. The next turn's model call to Anthropic 400s with the error above, naming the first, human-approved call's tool_use id as the one missing a tool_result. From that point on, every subsequent message in the session fails identically, since eve keeps resending the same corrupted history.

I instrumented nothing in the built output for this one — this is from production usage of a Next.js app using @eve/react's chat hook against eve's session/stream API. I confirmed there's no custom code in the app that constructs or replays the Anthropic message array; the app only renders/forwards eve's own session/stream events, so the corrupted history is assembled entirely inside eve's harness.

I traced through node_modules/eve/dist/src/harness/{tool-loop,input-requests,input-extraction}.js and node_modules/ai/dist/index.js (ai@7.0.4) trying to find the exact defect:

• Ruled out: the tool's execute throwing (it didn't — the HubSpot property-name validation the tool does locally didn't reject either payload).
• Ruled out: an approvalKey collision between the two same-tool-name calls causing them to be matched to the wrong approval response — each tool_use gets an independent approval request keyed by toolCallId/approvalId in the AI SDK (resolveToolApproval, collectToolApprovals), and eve's approvalKey only affects what gets recorded into the session's approvedTools set for future once() checks, not response matching.
• Still open: something in the approval-resume path (resolvePendingInput in input-requests.js, and/or handleStepResult in tool-loop.js) appears to let the harness proceed to build the next model request before the approved tool's actual (async, network-bound) execution result is durably appended to session history — i.e. the tool call resolves and its side effect fires, but the harness doesn't wait for/persist that specific tool_result before continuing the loop.

This looks related to the general fragility around HITL approval-resume + multi-round tool history reconstruction already visible in #203 (duplicate tool_result for client-resolved tools on resume) and #236 (approve-resume crash on OpenAI: "No tool output found for function call"), but distinct from both — here the tool is a normal execute-based approval-gated tool (not client-resolved), and the failure is a missing result rather than a duplicate one.

Steps to reproduce

1. npx eve@latest init repro
2. agent/agent.ts: export default defineAgent({ model: anthropic("claude-sonnet-4-6") }) (direct @ai-sdk/anthropic provider, not the AI Gateway model-reference string).
3. Add an authored tool with approval: once() and a real async execute that does non-trivial I/O (e.g. an await fetch(...) to an external API — the delay seems relevant, since a fast/instant execute may not reproduce it).
4. Give the agent a skill/instruction that calls this tool twice with different inputs in one user turn (e.g. "create object A, then create object B" using the same tool).
5. Approve the first (human-gated) call when prompted.
6. Watch the second, auto-approved (once()-satisfied) call complete, then send any further message in the same session.
7. The next model call to Anthropic 400s with tool_use ids were found without tool_result blocks immediately after: <id>, where <id> is the first, human-approved call's id — even though its side effect actually ran.

Expected behavior

After a human approves a HITL-gated tool call, eve should durably persist that specific tool call's tool_result into session history before advancing the turn/loop, so every tool_use block always has a matching tool_result in the next Anthropic request — regardless of how long the approved tool's execute takes to resolve, and regardless of whether other tool calls in the same turn complete first.

[edoardorinaldi]

Found a second, distinct trigger for this — same symptom, but the "ruled out: execute throwing" cause above turns out to apply in the same app, under eve@0.17.1 / Node v24.18.0 (same versions as the original report).

In this case the first, human-approved call's execute does throw synchronously — a local validation guardrail in the tool (hubspot_create_object) rejects unknown properties before making any network call:

if (unknown.length > 0) {
  throw new Error(`${unknown.join(", ")} ... is not a valid ${objectType} property...`);
}

Repro:

1. Fresh eval session, first turn: agent calls hubspot_create_object (approval: once()) with a payload containing properties outside the tool's allow-list.
2. Approve the call (tried both a plain-text "approve" reply and the structured respondAll("approve") API — same result either way).
3. The approved call resolves — its execute throws the validation error synchronously, no network I/O involved.
4. The very next model call to Anthropic 400s:

   messages.2: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_015rWKEKuSazqKxFnbNSfet8. Each `tool_use` block must have a corresponding `tool_result` block in the next message.
   

5. Session ends session.failed. Reproduced identically on two independent runs (different toolu_ ids, same shape).

Two differences from the original report worth noting:

• No second same-tool call is needed to trigger it — this happens on the first approval-gated call of the session, immediately after its execute throws.
• The failing result here is a synchronous throw, not a slow/successful async resolution — so "the tool's execute throwing" isn't ruled out in general, just wasn't the cause in the original two repros.

This fits the same "expected behavior" gap you described: eve isn't durably persisting the approved call's tool_result (success or error) into session history before advancing the loop — here it's just a zero-latency throw instead of a slow network call, which suggests the race isn't purely about execute duration.

Happy to share the minimal eval script (an eve/evals defineEval test case) that reproduces this on demand if useful.

[armorer-labs]

The second trigger is a useful narrowing signal because it suggests the invariant is not only "wait for slow async execute." The approval-resume path needs to publish a terminal tool_result for the approved tool_use before any later model request is assembled, even when execute throws synchronously or before network I/O starts.

The negative test I would pin is roughly:

1. model emits approval-gated tool_use A;
2. user approves A;
3. A enters execution and throws immediately;
4. the session history still gets the Anthropic-required adjacent tool_result for A, with an error/denied/failed status and a stable tool_call_id;
5. only after that write is durable can the loop continue, run same-tool auto-approved call B, or accept the next user turn.

That makes approval resume behave more like a small two-phase state machine than a UI event:

• approval_requested(A)
• approval_granted(A)
• execution_started(A)
• exactly one terminal result for A: success, tool_error, denied, cancelled, or expired
• next model request may be built only after every prior tool_use has that terminal result in message history

Two extra edge cases seem worth covering from an ops perspective:

• once() should not let a later same-tool call mask the missing terminal result for the originally human-approved call. Session trust can affect whether B prompts, but it should not change the required result accounting for A.
• if the process crashes between approval and terminal-result persistence, recovery should reconcile the pending approved call into an explicit failed/cancelled result rather than replaying a history with a dangling tool_use.

Disclosure: I work on Armorer Labs.

[Lukavyi]

Filed #529 for a distinct trigger of the same invariant violation, with the mechanism fully traced: on the Linear channel the approval-answering prompt always carries channel context, which the harness appends after the tool-approval-response tool message — so the AI SDK's collectToolApprovals (which only inspects the last message) never collects the approval and the approved tool never executes at all. Different from this issue (here the tool demonstrably ran / threw), but both reduce to the same missing guarantee spelled out above: every parked tool_use must get a terminal tool_result adjacent in history before the next model request is assembled. #529 includes a deterministic no-code repro and a production workaround (pnpm patch).

[armorer-labs]

That Linear-channel repro is a good separation of the invariant from the executor path. In both cases the failure is not really "approval UI did something odd"; it is that the resume path allowed the transcript builder to advance while an earlier tool_use still lacked a terminal adjacent result.

The fix I would want to see is probably one layer below individual channels:

• when a tool use enters approval wait, persist a pending transcript obligation keyed by the provider tool_use id;
• only the approval resolver/executor may close that obligation, and it must close it with exactly one terminal tool_result state: denied, tool_error, success, cancelled/expired;
• the next model-request assembler refuses to run while any obligation from the previous assistant turn is open, even if later user/channel context arrived;
• channel-specific approval messages can influence the decision, but should never be appended in a way that hides the approval response from the collector or bypasses the obligation check.

That would make the Linear ordering bug and the synchronous-throw bug fall out as the same regression class, which is a much easier contract to test than one-off channel fixes.

Disclosure: I work on Armorer Labs.

[rpelevin]

One way I would frame the fix is as a transcript-obligation invariant rather than only an approval-resume ordering bug.

When the provider emits a tool_use that enters approval wait, the harness has created an obligation against that exact provider id. Approval, denial, throw, cancellation, expiry, or crash recovery can choose the terminal state, but the next model request should not be assembled until that obligation is closed by exactly one adjacent tool_result.

That gives you a testable contract for the triggers in this issue:

• approved execute succeeds slowly: close with success after the side-effect result is durable
• approved execute throws before I/O: close with tool_error, not a dangling tool_use
• channel context arrives after approval: it can update session context, but cannot bypass the open obligation
• once() permits a later same-tool call without another prompt, but it does not satisfy the original call's result obligation

The recovery rule is the important one: if the process restarts after approval but before terminal-result persistence, reconstruct an explicit cancelled or failed result for that provider tool_use id before replaying history. Otherwise the transcript can look approved to the human, executed in the world, and invalid to the provider at the same time.

Boundary: architecture and conformance feedback only; no claim about running eve, implementation correctness, Vercel alignment, acceptance, partnership, integration, customer interest, official alignment, project usage, adoption, or Neura usage.