fix: strip empty tool_calls before sending to strict APIs

[webtecnica]

Problem

Conversations with 100+ messages on strict providers (DeepSeek, Mistral, Fireworks, Moonshot/Kimi) eventually hit:

HTTP 400: Invalid 'messages[409].tool_calls': empty array. Expected an array with minimum length 1, but got an empty array instead.

This happens because a message in the conversation history carries tool_calls: [] instead of having no tool_calls field. The empty array gets replayed verbatim to the provider, which rejects it.

Root cause

Two paths converge:

1. get_messages_as_conversation (hermes_state.py): when the DB stores "[]" (JSON-encoded empty array), it's parsed and set as msg["tool_calls"] = [] — the key is present with an empty list.

2. _sanitize_tool_calls_for_strict_api (run_agent.py): checks isinstance(tool_calls, list) but doesn't guard against empty lists, so [] passes through unchanged to the provider.

Fix

Two defence layers:

• hermes_state.py — only set tool_calls on the hydrated message if the parsed JSON is non-empty.
• run_agent.py — in _sanitize_tool_calls_for_strict_api, pop the key entirely when tool_calls is an empty list.

The first layer prevents [] from entering the live history; the second catches any remaining case at the API boundary.

Verification

• Existing strict API validation tests pass (4/4)
• Tool call incremental persistence tests pass (3/3)
• Message sequence repair tests pass (33/33)
• Syntax-checked with ast.parse

Changes

File	Δ
run_agent.py	+5 lines (guard in _sanitize_tool_calls_for_strict_api)
hermes_state.py	+2/−1 (only set tool_calls when parsed result is non-empty)

[webtecnica]

Rebased on latest main (was 57 commits behind). ✅

Relevant tests passing:

• tests/tools/test_hardline_blocklist.py: 185/185 passed
• tests/tools/test_cron_approval_mode.py: clean
• tests/tools/test_execute_code_approval_cluster.py: only pre-existing test failure unrelated to this change

No diff changes — same fix, just refreshed on top of current main. Ready for review.

[webtecnica]

@teknium1 This small fix (8 lines) resolves HTTP 400 on strict providers when empty tool_calls are replayed from conversation history. Freshly rebased on main, ready for review whenever you have a moment. 🙏

[teknium1]

The empty-array root cause you identified was correct — fixed via PR #59110 (salvage of #58768 by @xxxigm, submitted first with tests). Your PR took the same diagnosis but fixed it at two narrower sites (SQLite replay + _sanitize_tool_calls_for_strict_api); #58768's single unconditional final-chokepoint strip in sanitize_api_messages catches every source path (resume, host-fed histories, repair merges) regardless of provider, and does it non-destructively so persisted history and prompt caching stay byte-stable — so that implementation was merged. Both of you correctly identified the bug; closing this one as a duplicate with credit. Thanks!