mirror of
https://github.com/patriceckhart/zot.git
synced 2026-06-26 21:36:31 +02:00
c16e929f32
Resuming a session whose transcript contains an assistant
tool_use block without a matching tool_result in the next
message caused Anthropic (and OpenAI's responses API) to
refuse the first request with:
http 400: messages.N: `tool_use` ids were found without
`tool_result` blocks immediately after: toolu_...
Two ways the corrupt state gets onto disk:
- Older zot builds persisted the assistant tool_use row
before the tool_result row, then crashed or were killed
between the two writes.
- Earlier abort paths didn't drop the mid-turn assistant
message cleanly before it reached the session file.
OpenSession now passes the hydrated message slice through
repairToolUseResultPairs before returning it. For every
assistant tool_use whose id isn't covered by a tool_result in
the next message, the repair injects a stub
ToolResultBlock{
CallID: <id>,
Content: [TextBlock{"tool call was aborted; no result recorded."}],
IsError: true,
}
The stub is merged into the following tool-role message if
one exists (preserves row count), otherwise a new tool-role
message is inserted right after the assistant. Model sees
the aborted context and decides whether to retry.
Runs once per OpenSession call; the hot runtime path is
untouched. Live abort handling already drops partial
assistant messages, so this is purely a safety net for
legacy-corrupted files and the crash-between-writes case.
Tests in session_repair_test.go cover:
- stub appended when no tool-role message follows
- stub merged into partial tool-role message
- valid transcripts pass through unchanged
- nil/empty input handled safely
|
||
|---|---|---|
| .. | ||
| agent | ||
| assets | ||
| auth | ||
| core | ||
| extproto | ||
| provider | ||
| skills | ||
| tui | ||