fix(llmloop): guard nil tool-call arguments map to prevent panic

[chethanuk]

Problem

ocr scan (and potentially review) crashes with panic: assignment to entry in nil map at internal/llmloop/loop.go in executeToolCall, killing the per-file subtask:

panic: assignment to entry in nil map
github.com/open-code-review/open-code-review/internal/llmloop.(*Runner).executeToolCall(...)
    internal/llmloop/loop.go:324
github.com/open-code-review/open-code-review/internal/llmloop.(*Runner).RunPerFile(...)
    internal/scan.(*Agent).executeSubtask → dispatchBatch

Reported with GLM via an OpenAI-compatible endpoint; reproduces at any --concurrency, but only on files where the model emits the offending tool call — matching the reporter's partial-failure sessions ("5 completed, 4 failed").

Root cause

Some OpenAI-compatible gateways emit "arguments": null for tool calls. json.Unmarshal([]byte("null"), &args) returns nil error and leaves the map nil. The code_comment path-override then writes into it:

var args map[string]any
if err := json.Unmarshal([]byte(call.Function.Arguments), &args); err != nil { ... } // "null" passes
...
if t == tool.CodeComment && newPath != "" {
    args["path"] = newPath // panic: assignment to entry in nil map
}

This is the only nil-map write in the tool-call handling surface (audited every Function.Arguments unmarshal in the repo), but the dynamic-tool path has the same latent hazard: providers receive a nil args map and would panic if they ever write to it.

Fix

1. internal/llmloop/loop.go — both argument-unmarshal sites in executeToolCall now go through a shared parseToolArgs helper that always returns a non-nil map, so every downstream consumer (ParseComments, provider Execute, the code_comment path override) is safe. A null-args code_comment call now degrades gracefully to the existing "'comments' array is required" tool-error result, which the model can react to — instead of killing the subtask.
2. internal/llm/client.go — the Anthropic history-replay path had the same latent hazard: argsMap is pre-initialized, but json.Unmarshal([]byte("null"), &argsMap) resets it to nil (JSON null sets maps to nil regardless of prior value), so tool_use input would serialize as JSON null, which the API rejects. Guarded the same way.

Intentional behavior note: for dynamic/MCP tools called with arguments: null, the wire payload to the MCP server changes from "arguments": null to "arguments": {} — the standards-conformant encoding (JSON-Schema type: object validators reject null).

Tests

• New table-driven TestExecuteToolCall_ArgumentsEdgeCases (internal/llmloop): null args on code_comment (the exact panic: assignment to entry in nil map alibaba/open-code-review#382 repro — panics before this fix), {}, valid args (path-override behavior preserved), empty string, malformed JSON, and null args on a dynamic tool (asserts Execute receives a non-nil map).
• New table-driven TestBuildAnthropicParams_NullToolCallArguments (internal/llm): null/empty/{} arguments → tool_use input is always a non-nil object (fails on the nil map before the fix).

Both tests verified RED before the fix, GREEN after:

$ go test ./internal/llmloop/ ./internal/llm/ -race -count=1
ok  (325 tests, 2 packages)

make check, make test (-race), make coverage (81%+, ≥80% gate) and go build ./cmd/opencodereview all pass.

Fixes alibaba#382

[coderabbitai]

Warning

Review limit reached

@chethanuk, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 23 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9aa95d56-b9ef-47d5-bf1b-73f15f2b2c24

📥 Commits

Reviewing files that changed from the base of the PR and between 0b226fa and 850c99d.

📒 Files selected for processing (4)

• internal/llm/client.go
• internal/llm/client_test.go
• internal/llmloop/loop.go
• internal/llmloop/loop_test.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/llmloop-nil-tool-args

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request prevents potential panics by ensuring that tool call arguments that unmarshal to nil (such as when "arguments": null is received) are initialized to a non-nil map before being used. Comprehensive unit tests have been added to verify these edge cases. There are no review comments, so no feedback is provided.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.