💻 Change Type

• 🐛 fix

🔗 Related Issue

Closes LOBE-8199.

🔀 Description of Change

Some providers (NVIDIA NIM serving z-ai/glm5 and qwen/qwen3.5-397b-a17b, plus some aihubmix-style proxies) open a streaming tool_call delta with function.name = null as a start marker, and only supply the real name in a later delta. The strict MessageToolCallSchema threw ZodError mid-stream and killed the entire operation — in one sampled op the agent had been running for 58 minutes and 113 steps before dying on this.

path: ["function", "name"]
expected: "string"  received: "null"

This behavior is the same shape that the zhipu provider already preprocesses per-provider (see zhipu/index.ts:104). This PR promotes the same tolerance to the central aggregation layer so it covers any provider exhibiting the same streaming pattern, instead of handling it one provider at a time.

Changes:

• packages/model-runtime/src/helpers/parseToolCalls.ts — coerce function.name: null/undefined to '' before the Zod parse so streaming doesn't die; merge function.name from subsequent deltas (previously only arguments merged) so the real name patched in later replaces the placeholder. Once-resolved names are not overwritten by later empty-name deltas.

• src/server/modules/AgentRuntime/RuntimeExecutors.ts — defense-in-depth at the state persist boundary: drop tool_calls whose function.name never resolved to a non-empty string before pushing to state.messages. ToolNameResolver already filters these out of the dispatch path, but keeping them in replay history would still 400 on strict providers (which is exactly how this bug surfaced). Mirrors the existing LOBE-7761 sanitizeToolCallArguments pattern at the same boundary.

🧪 How to Test

• Tested locally
• Added/updated tests
• No tests needed

Unit tests in parseToolCalls.test.ts cover three new scenarios:

1. First delta with name: null + later delta patches in the real name + final delta appends arguments → full resolution.
2. New parallel tool_call opening with name: null is accepted when merging into existing tool_calls.
3. Already-resolved names are not overwritten by a later name: '' delta.

The existing "should throw error if incomplete tool calls data" test still passes — we only loosen for null name; chunks missing function entirely still throw.

bunx vitest run 'packages/model-runtime/src/helpers/parseToolCalls.test.ts'
  → 10 passed (7 existing + 3 new)

bunx vitest run 'packages/model-runtime/src/providers/zhipu'
  → 83 passed

bunx vitest run 'packages/model-runtime/src/core/streams'
  → 220 passed

bunx vitest run 'src/server/modules/AgentRuntime/__tests__/RuntimeExecutors.test.ts'
  → 93 passed

bun run type-check
  → clean

📝 Additional Information

Observed in 3 production ops (all on provider: nvidia):

Op 3's final step is particularly clarifying: the harness' existing TRUNCATED_ARGUMENTS path (builtin.ts:38) was already gracefully catching truncated arguments strings (extended-thinking exhausting max_tokens), but the same root cause producing name: null had no corresponding graceful path and took down the whole op. This PR closes that asymmetry at the aggregation layer.

🤖 Generated with Claude Code