fix(build): repair remaining package compilation failures (round 2)#958
Conversation
Round 2 build repair following PR #956. Brings the build from 15 failing packages with deep cascades down to 11 with shallower errors, with several packages (store, watcher/diff, managementasset, codex thinking, claude/gemini translator, config) now fully green. Changes: - pkg/llmproxy/auth/kiro: restore deleted runtime_helpers.go (buildURL, GetAccountKey, setRuntimeHeaders, FetchProfileArn wrapper, ParseProfileARN, GetKiroAPIEndpoint, sync.Once-backed GetGlobalFingerprintManager) so aws_auth.go, codewhisperer_client.go, oauth_web.go, and usage_checker.go compile. - pkg/llmproxy/config: add RemoteManagement.DisableAutoUpdatePanel field referenced by managementasset/updater.go. - pkg/llmproxy/store: migrate go-git/v6 alpha API drift — CloneOptions.Auth/PullOptions.Auth/PushOptions.Auth (removed) become ClientOptions []client.Option carrying client.WithHTTPAuth(BasicAuth). - pkg/llmproxy/thinking/provider/codex/apply.go: drop unused "strings" import. - pkg/llmproxy/translator/claude/gemini: add missing registry import. - pkg/llmproxy/watcher/diff: add diff_generated.go shim that hosts BuildConfigChangeDetailsGeneratedProviders for config_diff.go (lifted from pkg/llmproxy/auth/diff/diff_generated.go codegen output). - pkg/llmproxy/translator/*: replace removed sjson.SetBytesM with sjson.SetBytes; convert assorted string-typed JSON working buffers (template, out, completed, item, msg, sysMsg, textPart, etc.) to []byte so they remain compatible with sjson.SetBytes/SetRawBytes; rewire sjson.SetRaw -> sjson.SetRawBytes on those buffers; switch emitRespEvent payload param to []byte; convert gjson.Parse(byteVar) to gjson.ParseBytes where the input is now []byte. Remaining failures are deeper kiro symbol drift (FingerprintConfig, KiroFingerprint config field, FetchUserEmailWithFallback signature change, GlobalFingerprintManager) plus per-file inline JSON-buffer conversions in 11 translator files; tracked separately for round 3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 32 minutes and 15 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (26)
Note
|
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request is the second round of efforts to resolve compilation failures across the repository. The changes focus on API migrations, specifically updating sjson usage to align with newer library requirements, and restoring functionality to several key packages. These improvements have successfully reduced the total number of failing packages and set the stage for final build stabilization in the next round. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
codeant-ai
Bot
added
the
size:XL
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| inputResult := gjson.GetBytes(rawJSON, "input") | ||
| if inputResult.Type == gjson.String { | ||
| input, _ := sjson.SetBytesM(`[{"type":"message","role":"user","content":[{"type":"input_text","text":""}]}]`, "0.content.0.text", inputResult.String()) | ||
| input, _ := sjson.SetBytes(`[{"type":"message","role":"user","content":[{"type":"input_text","text":""}]}]`, "0.content.0.text", inputResult.String()) |
There was a problem hiding this comment.
Suggestion: This function is already over the 40-line limit and was modified in this PR; extract the new input-string normalization into a small helper to keep the main request conversion flow below the threshold. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The suggestion is consistent with the final file: ConvertOpenAIResponsesRequestToCodex is a large function well over 40 lines, and this new input-normalization logic contributes to that size. Extracting it into a helper would address the stated function-length rule.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/openai/responses/codex_openai-responses_request.go
**Line:** 37:37
**Comment:**
*Custom Rule: This function is already over the 40-line limit and was modified in this PR; extract the new input-string normalization into a small helper to keep the main request conversion flow below the threshold.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| fnRaw, _ = sjson.SetBytes(fnRaw, "name", name) | ||
| item := []byte(`{}`) | ||
| item, _ = sjson.SetBytes(item, "type", "function") | ||
| item, _ = sjson.SetRawBytes(item, "function", fnRaw) |
There was a problem hiding this comment.
Suggestion: This modified function exceeds 40 lines; move the rebuilt tool-item construction logic into a dedicated helper so the normalization loop remains focused and shorter. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The updated normalizeResponseTools function is also well beyond 40 lines in the final file. The added reconstruction of the tool item is part of that oversized function, so the suggestion accurately identifies a real function-length violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/openai/responses/codex_openai-responses_request.go
**Line:** 201:204
**Comment:**
*Custom Rule: This modified function exceeds 40 lines; move the rebuilt tool-item construction logic into a dedicated helper so the normalization loop remains focused and shorter.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| out, _ = sjson.SetBytes(out, "request.generationConfig.thinkingConfig.thinkingBudget", budget) | ||
| out, _ = sjson.SetBytes(out, "request.generationConfig.thinkingConfig.includeThoughts", true) | ||
| } | ||
| case "adaptive": | ||
| // Keep adaptive as a high level sentinel; ApplyThinking resolves it | ||
| // to model-specific max capability. | ||
| out, _ = sjson.SetBytesM(out, "request.generationConfig.thinkingConfig.thinkingLevel", "high") | ||
| out, _ = sjson.SetBytesM(out, "request.generationConfig.thinkingConfig.includeThoughts", true) | ||
| out, _ = sjson.SetBytes(out, "request.generationConfig.thinkingConfig.thinkingLevel", "high") | ||
| out, _ = sjson.SetBytes(out, "request.generationConfig.thinkingConfig.includeThoughts", true) | ||
| } | ||
| } | ||
| if v := gjson.GetBytes(rawJSON, "temperature"); v.Exists() && v.Type == gjson.Number { | ||
| out, _ = sjson.SetBytesM(out, "request.generationConfig.temperature", v.Num) | ||
| out, _ = sjson.SetBytes(out, "request.generationConfig.temperature", v.Num) | ||
| } | ||
| if v := gjson.GetBytes(rawJSON, "top_p"); v.Exists() && v.Type == gjson.Number { | ||
| out, _ = sjson.SetBytesM(out, "request.generationConfig.topP", v.Num) | ||
| out, _ = sjson.SetBytes(out, "request.generationConfig.topP", v.Num) | ||
| } | ||
| if v := gjson.GetBytes(rawJSON, "top_k"); v.Exists() && v.Type == gjson.Number { | ||
| out, _ = sjson.SetBytesM(out, "request.generationConfig.topK", v.Num) | ||
| out, _ = sjson.SetBytes(out, "request.generationConfig.topK", v.Num) |
There was a problem hiding this comment.
Suggestion: Refactor the newly added generation-config mapping logic into a dedicated helper and keep ConvertClaudeRequestToCLI focused on orchestration so the modified function body stays within the 40-line limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The function now contains several newly added generation-config assignments inside ConvertClaudeRequestToCLI, which contributes to the function exceeding the stated 40-line limit. Refactoring this logic into a helper would address the custom size rule.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini-cli/claude/gemini-cli_claude_request.go
**Line:** 186:203
**Comment:**
*Custom Rule: Refactor the newly added generation-config mapping logic into a dedicated helper and keep `ConvertClaudeRequestToCLI` focused on orchestration so the modified function body stays within the 40-line limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| promptTokenCount := usageResult.Get("promptTokenCount").Int() - cachedTokenCount | ||
| thoughtsTokenCount := usageResult.Get("thoughtsTokenCount").Int() | ||
| template, _ = sjson.SetBytesM(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) | ||
| template, _ = sjson.SetBytes(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) |
There was a problem hiding this comment.
Suggestion: Since this change modifies a function whose body is far over 40 lines, extract the usage-metadata update block into a dedicated helper so the main conversion function stays within the size limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The modified function is well over 40 lines long, and the usage-metadata logic is embedded directly inside it. This matches the suggestion's stated size-limit concern, so the rule violation is present in the existing code.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/antigravity/openai/chat-completions/antigravity_openai_response.go
**Line:** 106:106
**Comment:**
*Custom Rule: Since this change modifies a function whose body is far over 40 lines, extract the usage-metadata update block into a dedicated helper so the main conversion function stays within the size limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| msg := []byte(`{"role":"","content":[]}`) | ||
| msg, _ = sjson.SetBytes(msg, "role", role) | ||
|
|
||
| // Handle content based on its type (string or array) | ||
| if contentResult.Exists() && contentResult.Type == gjson.String && contentResult.String() != "" { | ||
| part := `{"type":"text","text":""}` | ||
| part, _ = sjson.SetBytesM(part, "text", contentResult.String()) | ||
| msg, _ = sjson.SetRaw(msg, "content.-1", part) | ||
| part := []byte(`{"type":"text","text":""}`) | ||
| part, _ = sjson.SetBytes(part, "text", contentResult.String()) | ||
| msg, _ = sjson.SetRawBytes(msg, "content.-1", part) |
There was a problem hiding this comment.
Suggestion: Split the expanded message/tool transformation logic into dedicated helper functions so the modified function body stays under the 40-line limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The function ConvertOpenAIRequestToClaude is much longer than 40 lines in the final file, and this snippet is part of that oversized body. The suggestion correctly identifies a real function-length rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request.go
**Line:** 167:174
**Comment:**
*Custom Rule: Split the expanded message/tool transformation logic into dedicated helper functions so the modified function body stays under the 40-line limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| out, _ = sjson.SetBytes(out, "generationConfig.thinkingConfig.thinkingBudget", budget) | ||
| out, _ = sjson.SetBytes(out, "generationConfig.thinkingConfig.includeThoughts", true) | ||
| } | ||
| case "adaptive": | ||
| // Keep adaptive as a high level sentinel; ApplyThinking resolves it | ||
| // to model-specific max capability. | ||
| out, _ = sjson.SetBytesM(out, "generationConfig.thinkingConfig.thinkingLevel", "high") | ||
| out, _ = sjson.SetBytesM(out, "generationConfig.thinkingConfig.includeThoughts", true) | ||
| out, _ = sjson.SetBytes(out, "generationConfig.thinkingConfig.thinkingLevel", "high") | ||
| out, _ = sjson.SetBytes(out, "generationConfig.thinkingConfig.includeThoughts", true) | ||
| } | ||
| } | ||
| if v := gjson.GetBytes(rawJSON, "temperature"); v.Exists() && v.Type == gjson.Number { | ||
| out, _ = sjson.SetBytesM(out, "generationConfig.temperature", v.Num) | ||
| out, _ = sjson.SetBytes(out, "generationConfig.temperature", v.Num) | ||
| } | ||
| if v := gjson.GetBytes(rawJSON, "top_p"); v.Exists() && v.Type == gjson.Number { | ||
| out, _ = sjson.SetBytesM(out, "generationConfig.topP", v.Num) | ||
| out, _ = sjson.SetBytes(out, "generationConfig.topP", v.Num) | ||
| } | ||
| if v := gjson.GetBytes(rawJSON, "top_k"); v.Exists() && v.Type == gjson.Number { | ||
| out, _ = sjson.SetBytesM(out, "generationConfig.topK", v.Num) | ||
| out, _ = sjson.SetBytes(out, "generationConfig.topK", v.Num) |
There was a problem hiding this comment.
Suggestion: Extract the newly added thinking and generation-config mapping block into dedicated helper functions so the modified converter no longer exceeds the 40-line function-body limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The final file still contains a large single function body in ConvertClaudeRequestToGemini, and the added generationConfig mapping block is part of that function. The snippet shown is real and the function clearly exceeds the stated 40-line limit, so this is a genuine violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/claude/gemini_claude_request.go
**Line:** 179:196
**Comment:**
*Custom Rule: Extract the newly added thinking and generation-config mapping block into dedicated helper functions so the modified converter no longer exceeds the 40-line function-body limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| promptTokenCount := usageResult.Get("promptTokenCount").Int() - cachedTokenCount | ||
| thoughtsTokenCount := usageResult.Get("thoughtsTokenCount").Int() | ||
| baseTemplate, _ = sjson.SetBytesM(baseTemplate, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) | ||
| baseTemplate, _ = sjson.SetBytes(baseTemplate, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) |
There was a problem hiding this comment.
Suggestion: This function is already far above the 40-line limit and was modified in this PR; extract usage-metadata mapping into a dedicated helper to keep the main conversion flow smaller and easier to maintain. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The streaming conversion function is well over the 40-line limit in the final file state, and the highlighted usage-metadata logic is part of that oversized function. The suggestion correctly identifies a real function-size rule violation and proposes a valid refactor.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/openai/chat-completions/gemini_openai_response.go
**Line:** 111:111
**Comment:**
*Custom Rule: This function is already far above the 40-line limit and was modified in this PR; extract usage-metadata mapping into a dedicated helper to keep the main conversion flow smaller and easier to maintain.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| thoughtsTokenCount := usageResult.Get("thoughtsTokenCount").Int() | ||
| cachedTokenCount := usageResult.Get("cachedContentTokenCount").Int() | ||
| template, _ = sjson.SetBytesM(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) | ||
| template, _ = sjson.SetBytes(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) |
There was a problem hiding this comment.
Suggestion: This modified non-streaming conversion function also exceeds the 40-line threshold; move token-usage population into a helper function so the main handler stays within the size rule. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The non-streaming conversion function also exceeds the 40-line limit in the final file state, and this usage-metadata assignment occurs inside that oversized function. The suggestion matches a genuine size-based custom rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/openai/chat-completions/gemini_openai_response.go
**Line:** 311:311
**Comment:**
*Custom Rule: This modified non-streaming conversion function also exceeds the 40-line threshold; move token-usage population into a helper function so the main handler stays within the size rule.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| completed, _ = sjson.SetBytes(completed, "response.instructions", v.String()) | ||
| } | ||
| if v := req.Get("max_output_tokens"); v.Exists() { | ||
| completed, _ = sjson.SetBytesM(completed, "response.max_output_tokens", v.Int()) | ||
| completed, _ = sjson.SetBytes(completed, "response.max_output_tokens", v.Int()) |
There was a problem hiding this comment.
Suggestion: Refactor the modified streaming converter by extracting repeated event-construction blocks into small helper functions so the parent function body stays under the 40-line limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The suggestion is about a function-length custom rule, and the streaming converter in the final file is far longer than 40 lines. The shown code is part of that oversized function body, so the rule violation is real and the suggestion is verified.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/openai/responses/gemini_openai-responses_response.go
**Line:** 435:438
**Comment:**
*Custom Rule: Refactor the modified streaming converter by extracting repeated event-construction blocks into small helper functions so the parent function body stays under the 40-line limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| resp, _ = sjson.SetBytes(resp, "instructions", v.String()) | ||
| } | ||
| if v := req.Get("max_output_tokens"); v.Exists() { | ||
| resp, _ = sjson.SetBytesM(resp, "max_output_tokens", v.Int()) | ||
| resp, _ = sjson.SetBytes(resp, "max_output_tokens", v.Int()) | ||
| } | ||
| if v := req.Get("max_tool_calls"); v.Exists() { | ||
| resp, _ = sjson.SetBytesM(resp, "max_tool_calls", v.Int()) | ||
| resp, _ = sjson.SetBytes(resp, "max_tool_calls", v.Int()) | ||
| } | ||
| if v := req.Get("model"); v.Exists() { | ||
| resp, _ = sjson.SetBytesM(resp, "model", v.String()) | ||
| resp, _ = sjson.SetBytes(resp, "model", v.String()) |
There was a problem hiding this comment.
Suggestion: Break the modified non-stream converter into dedicated helpers for metadata mapping, output assembly, and usage mapping so each function body remains within 40 lines. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The non-stream converter in the final file is also much longer than 40 lines, so it violates the stated function-length rule. The cited code is within that oversized function body, making this a real violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/openai/responses/gemini_openai-responses_response.go
**Line:** 595:604
**Comment:**
*Custom Rule: Break the modified non-stream converter into dedicated helpers for metadata mapping, output assembly, and usage mapping so each function body remains within 40 lines.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| msgJSON, _ = sjson.SetRawBytes(msgJSON, "content", contentArrayJSON) | ||
|
|
||
| messagesJSON, _ = sjson.SetBytesM(messagesJSON, "-1", gjson.Parse(msgJSON).Value()) | ||
| messagesJSON, _ = sjson.SetBytes(messagesJSON, "-1", gjson.ParseBytes(msgJSON).Value()) |
There was a problem hiding this comment.
Suggestion: The modified ConvertClaudeRequestToOpenAI function is far above the 40-line limit; extract the non-assistant message append path into a small helper and call it here so this function stays within the rule. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The custom rule is about keeping the modified function under the 40-line limit. In the final file, ConvertClaudeRequestToOpenAI spans far more than 40 lines, so this suggestion identifies a real rule violation rather than a stylistic preference.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/openai/claude/openai_claude_request.go
**Line:** 258:258
**Comment:**
*Custom Rule: The modified `ConvertClaudeRequestToOpenAI` function is far above the 40-line limit; extract the non-assistant message append path into a small helper and call it here so this function stays within the rule.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces several changes across the codebase, including the addition of AWS CodeWhisperer runtime helpers, configuration options for management UI updates, and a significant refactoring of JSON manipulation logic to use byte-based operations for better performance. However, numerous type mismatch issues were identified in the refactored JSON code that will cause compilation errors, specifically where sjson.SetBytes or sjson.SetRawBytes are called with string arguments instead of []byte. Additionally, a potential issue with cache pollution was noted in the account key generation logic when stable identifiers are missing.
| part, _ = sjson.SetBytesM(part, "data", text) | ||
| part := []byte(`{"type":"redacted_thinking","data":""}`) | ||
| part, _ = sjson.SetBytes(part, "data", text) | ||
| return part |
There was a problem hiding this comment.
The function buildRedactedThinkingPart is declared to return a string, but part is a []byte. This will cause a compilation error. Convert the result to a string before returning.
| return part | |
| return string(part) |
| } | ||
| partJSON := `{}` | ||
| partJSON, _ = sjson.SetBytesM(partJSON, "text", systemPrompt) | ||
| partJSON, _ = sjson.SetBytes(partJSON, "text", systemPrompt) |
There was a problem hiding this comment.
sjson.SetBytes expects a []byte as its first argument, but partJSON is a string. To fix the compilation error while keeping partJSON as a string, use sjson.Set instead.
| partJSON, _ = sjson.SetBytes(partJSON, "text", systemPrompt) | |
| partJSON, _ = sjson.Set(partJSON, "text", systemPrompt) |
| argsJSON := gjson.Parse(argsStr) | ||
| if argsJSON.IsObject() { | ||
| toolUse, _ = sjson.SetRaw(toolUse, "input", argsJSON.Raw) | ||
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", argsJSON.Raw) |
There was a problem hiding this comment.
sjson.SetRawBytes expects a []byte for the value argument. Since argsJSON.Raw is a string, it must be converted to []byte to satisfy the type requirements.
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", argsJSON.Raw) | |
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", []byte(argsJSON.Raw)) |
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", argsJSON.Raw) | ||
| } else { | ||
| toolUse, _ = sjson.SetRaw(toolUse, "input", "{}") | ||
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", "{}") |
There was a problem hiding this comment.
sjson.SetRawBytes expects a []byte for the value argument. The string literal "{}" should be converted to []byte.
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", "{}") | |
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", []byte("{}")) |
| // Convert parameters schema for the tool | ||
| if parameters := function.Get("parameters"); parameters.Exists() { | ||
| anthropicTool, _ = sjson.SetRaw(anthropicTool, "input_schema", parameters.Raw) | ||
| anthropicTool, _ = sjson.SetRawBytes(anthropicTool, "input_schema", parameters.Raw) |
There was a problem hiding this comment.
sjson.SetRawBytes expects a []byte for the value argument. parameters.Raw is a string and needs conversion.
| anthropicTool, _ = sjson.SetRawBytes(anthropicTool, "input_schema", parameters.Raw) | |
| anthropicTool, _ = sjson.SetRawBytes(anthropicTool, "input_schema", []byte(parameters.Raw)) |
| out, _ = sjson.SetBytesM(out, "additionalProperties", false) | ||
| out, _ = sjson.SetBytes(out, "additionalProperties", false) | ||
| } | ||
| return out |
There was a problem hiding this comment.
The function NormalizeOpenAIFunctionSchemaForGemini is declared to return a string, but out is a []byte. This will cause a compilation error.
| return out | |
| return string(out) |
| item := []byte(`{"id":"","type":"reasoning","summary":[{"type":"summary_text","text":""}]}`) | ||
| item, _ = sjson.SetBytes(item, "id", r.ReasoningID) | ||
| item, _ = sjson.SetBytes(item, "summary.0.text", r.ReasoningData) | ||
| outputsWrapper, _ = sjson.SetRaw(outputsWrapper, "arr.-1", item) |
There was a problem hiding this comment.
sjson.SetRaw expects a string for the value argument, but item is a []byte. Convert item to a string to fix the compilation error.
| outputsWrapper, _ = sjson.SetRaw(outputsWrapper, "arr.-1", item) | |
| outputsWrapper, _ = sjson.SetRaw(outputsWrapper, "arr.-1", string(item)) |
| } | ||
| if gjson.Get(outputsWrapper, "arr.#").Int() > 0 { | ||
| completed, _ = sjson.SetRaw(completed, "response.output", gjson.Get(outputsWrapper, "arr").Raw) | ||
| completed, _ = sjson.SetRawBytes(completed, "response.output", gjson.Get(outputsWrapper, "arr").Raw) |
There was a problem hiding this comment.
sjson.SetRawBytes expects a []byte for the value argument. gjson.Get(...).Raw is a string and needs conversion.
| completed, _ = sjson.SetRawBytes(completed, "response.output", gjson.Get(outputsWrapper, "arr").Raw) | |
| completed, _ = sjson.SetRawBytes(completed, "response.output", []byte(gjson.Get(outputsWrapper, "arr").Raw)) |
| } | ||
| if gjson.Get(outputsWrapper, "arr.#").Int() > 0 { | ||
| resp, _ = sjson.SetRaw(resp, "output", gjson.Get(outputsWrapper, "arr").Raw) | ||
| resp, _ = sjson.SetRawBytes(resp, "output", gjson.Get(outputsWrapper, "arr").Raw) |
There was a problem hiding this comment.
sjson.SetRawBytes expects a []byte for the value argument. gjson.Get(...).Raw is a string and needs conversion.
| resp, _ = sjson.SetRawBytes(resp, "output", gjson.Get(outputsWrapper, "arr").Raw) | |
| resp, _ = sjson.SetRawBytes(resp, "output", []byte(gjson.Get(outputsWrapper, "arr").Raw)) |
| if refreshToken != "" { | ||
| return GenerateAccountKey(refreshToken) | ||
| } | ||
| return GenerateAccountKey(uuid.New().String()) |
There was a problem hiding this comment.
Returning a random UUID when both clientID and refreshToken are empty might lead to cache pollution if this key is used for a per-account cache. Consider using a stable sentinel value or returning an empty string if no stable identifier is available to avoid creating unnecessary cache entries.
| // DisableAutoUpdatePanel skips the periodic auto-update of the bundled | ||
| // management UI asset while still serving the control panel itself. | ||
| DisableAutoUpdatePanel bool `yaml:"disable-auto-update-panel"` |
There was a problem hiding this comment.
🟠 Architect Review — HIGH
The new RemoteManagement.DisableAutoUpdatePanel toggle is not included in BuildConfigChangeDetails, so changing this setting is not reported in config reload diff output, unlike the other remote-management fields.
Suggestion: Extend watcher/diff/config_diff.go to compare oldCfg.RemoteManagement.DisableAutoUpdatePanel vs newCfg.RemoteManagement.DisableAutoUpdatePanel and append a formatted change entry (e.g., "remote-management.disable-auto-update-panel: false -> true"), matching the existing patterns and tests.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is an **Architect / Logical Review** comment left during a code review. These reviews are first-class, important findings — not optional suggestions. Do NOT dismiss this as a 'big architectural change' just because the title says architect review; most of these can be resolved with a small, localized fix once the intent is understood.
**Path:** pkg/llmproxy/config/config.go
**Line:** 203:205
**Comment:**
*HIGH: The new RemoteManagement.DisableAutoUpdatePanel toggle is not included in BuildConfigChangeDetails, so changing this setting is not reported in config reload diff output, unlike the other remote-management fields.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
If a suggested approach is provided above, use it as the authoritative instruction. If no explicit code suggestion is given, you MUST still draft and apply your own minimal, localized fix — do not punt back with 'no suggestion provided, review manually'. Keep the change as small as possible: add a guard clause, gate on a loading state, reorder an await, wrap in a conditional, etc. Do not refactor surrounding code or expand scope beyond the finding.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| promptTokenCount := usageResult.Get("promptTokenCount").Int() - cachedTokenCount | ||
| thoughtsTokenCount := usageResult.Get("thoughtsTokenCount").Int() | ||
| template, _ = sjson.SetBytesM(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) | ||
| template, _ = sjson.SetBytes(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) |
There was a problem hiding this comment.
Suggestion: thoughtsTokenCount represents reasoning/output tokens, but this line adds it to usage.prompt_tokens (input tokens). That misclassifies output tokens as prompt tokens and can produce inconsistent usage accounting (prompt_tokens + completion_tokens no longer reflects the true split), which breaks downstream billing/analytics expectations. Keep prompt tokens as prompt-only and account reasoning tokens under completion/output fields. [logic error]
Severity Level: Major ⚠️
- ❌ Antigravity OpenAI usage misattributes reasoning tokens as prompt.
- ⚠️ Usage logger `TokenStats.InputTokens` inflated for antigravity reasoning.
- ⚠️ TUI usage tab shows incorrect input versus reasoning totals.
- ⚠️ Provider analytics per-provider metrics skewed for antigravity sessions.Steps of Reproduction ✅
1. Trigger the antigravity → OpenAI chat-completions translator by calling
`ConvertAntigravityResponseToOpenAI` in
`pkg/llmproxy/translator/antigravity/openai/chat-completions/antigravity_openai_response.go:50`
with a Gemini CLI streaming chunk whose `response.usageMetadata` includes:
- `promptTokenCount`
- `candidatesTokenCount`
- `totalTokenCount`
- non-zero `thoughtsTokenCount`
- `cachedContentTokenCount`.
2. Inside `ConvertAntigravityResponseToOpenAI`, the usage block at
`antigravity_openai_response.go:95-107` executes:
- `promptTokenCount := usageResult.Get("promptTokenCount").Int() - cachedTokenCount`
(line 104),
- `thoughtsTokenCount := usageResult.Get("thoughtsTokenCount").Int()` (line 105),
- `template, _ = sjson.SetBytes(template, "usage.prompt_tokens",
promptTokenCount+thoughtsTokenCount)` (line 106),
- and, if `thoughtsTokenCount > 0`, `template, _ = sjson.SetBytes(template,
"usage.completion_tokens_details.reasoning_tokens", thoughtsTokenCount)` (line 108).
This produces an OpenAI-style chunk where `usage.prompt_tokens` already includes
reasoning/output tokens (`thoughtsTokenCount`), while
`usage.completion_tokens_details.reasoning_tokens` separately records them as reasoning
tokens.
3. Feed the resulting OpenAI-style JSON (for example, by wrapping the chunk into a
non-streaming response payload) through the shared usage parser `parseOpenAIUsage` in
`pkg/llmproxy/executor/usage_helpers.go:52-77`:
- `InputTokens` is read from `usage.prompt_tokens` (line 54),
- `OutputTokens` from `usage.completion_tokens` (line 55),
- `ReasoningTokens` from `usage.completion_tokens_details.reasoning_tokens` (lines
65-72).
Because `usage.prompt_tokens` already contains `promptTokenCount + thoughtsTokenCount`
and `ReasoningTokens` is set to `thoughtsTokenCount`, the same reasoning tokens are now
counted both as input tokens and as reasoning tokens.
4. Observe downstream effects in analytics/logging:
- `usageReporter.publishWithOutcome` in `pkg/llmproxy/executor/usage_helpers.go:63-73`
forwards this `usage.Detail` to `usage.PublishRecord`,
- `pkg/llmproxy/usage/logger_plugin.go:11-18` stores these as `TokenStats` where
`InputTokens` includes reasoning tokens, and `ReasoningTokens` also includes them,
- the TUI aggregation in `pkg/llmproxy/tui/usage_tab.go:10-26` then reports inflated
input token totals and separate reasoning totals, breaking the expected
prompt/completion split (prompt tokens are no longer pure input, they include
reasoning/output tokens).
This behavior contrasts with the canonical mapping in
`pkg/llmproxy/translator/openai/openai/responses/openai_openai-responses_response.go:13-25`,
where reasoning tokens are only mapped under
`usage.output_tokens_details.reasoning_tokens` and not added into
`usage.prompt_tokens`, showing that the antigravity translator's use of
`promptTokenCount+thoughtsTokenCount` for `usage.prompt_tokens` is inconsistent and
misclassifies reasoning/output tokens as prompt tokens.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/antigravity/openai/chat-completions/antigravity_openai_response.go
**Line:** 106:106
**Comment:**
*Logic Error: `thoughtsTokenCount` represents reasoning/output tokens, but this line adds it to `usage.prompt_tokens` (input tokens). That misclassifies output tokens as prompt tokens and can produce inconsistent usage accounting (`prompt_tokens + completion_tokens` no longer reflects the true split), which breaks downstream billing/analytics expectations. Keep prompt tokens as prompt-only and account reasoning tokens under completion/output fields.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| if refreshToken != "" { | ||
| return GenerateAccountKey(refreshToken) | ||
| } | ||
| return GenerateAccountKey(uuid.New().String()) |
There was a problem hiding this comment.
Suggestion: The fallback path generates a new UUID every time both identifiers are empty, which makes the "account key" non-stable and creates a new fingerprint entry on each call. Because fingerprints are cached in a process-wide map by key, this can cause unbounded map growth and inconsistent headers/rate-limit identity for the same logical anonymous caller. Use a deterministic fallback key instead of a per-call random UUID. [resource leak]
Severity Level: Major ⚠️
- ❌ Long-running quota checks leak memory via FingerprintManager map.
- ⚠️ Anonymous tokens send inconsistent User-Agent and x-amz-user-agent.Steps of Reproduction ✅
1. In application code, create a usage checker via `NewUsageChecker(cfg)` defined in
`pkg/llmproxy/auth/kiro/usage_checker.go:56-59`.
2. Call `checker.CheckUsageByAccessToken(ctx, accessToken, profileArn)` from
`usage_checker.go:120-126`, which builds a `KiroTokenData` with only `AccessToken` and
`ProfileArn` set (no `ClientID` or `RefreshToken`).
3. Inside `CheckUsage` (`usage_checker.go:70-96`), it computes `accountKey :=
GetAccountKey(tokenData.ClientID, tokenData.RefreshToken)` where both fields are empty,
causing `GetAccountKey` in `runtime_helpers.go:118-125` to execute the fallback `return
GenerateAccountKey(uuid.New().String())` on every call.
4. `setRuntimeHeaders` in `runtime_helpers.go:145-151` then calls
`GetGlobalFingerprintManager().GetFingerprint(accountKey)`, which stores a new entry in
`FingerprintManager.fingerprints` (`fingerprint.go:30-32, 83-101`) for each invocation;
repeated quota checks with only an access token cause the fingerprints map to grow
unboundedly and send inconsistent fingerprint-derived headers for the same logical caller.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/auth/kiro/runtime_helpers.go
**Line:** 125:125
**Comment:**
*Resource Leak: The fallback path generates a new UUID every time both identifiers are empty, which makes the "account key" non-stable and creates a new fingerprint entry on each call. Because fingerprints are cached in a process-wide map by key, this can cause unbounded map growth and inconsistent headers/rate-limit identity for the same logical anonymous caller. Use a deterministic fallback key instead of a per-call random UUID.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| case "response.created": // Handle response creation - set model and response ID | ||
| template, _ = sjson.SetBytesM(template, "modelVersion", rootResult.Get("response.model").String()) | ||
| template, _ = sjson.SetBytesM(template, "responseId", rootResult.Get("response.id").String()) | ||
| template, _ = sjson.SetBytes(template, "modelVersion", rootResult.Get("response.model").String()) |
There was a problem hiding this comment.
Suggestion: This overwrites modelVersion with the upstream Codex model from the event payload, even though the translator output is Gemini-format and earlier in the same function modelVersion is initialized from the target model parameter. This creates inconsistent API contract behavior across events and can mislead downstream clients about which model produced the response. [logic error]
Severity Level: Major ⚠️
- ⚠️ Codex→Gemini streaming responses misreport `modelVersion` field.
- ⚠️ Gemini clients see upstream Codex model identifier.
- ⚠️ Stream vs non-stream Gemini responses disagree on `modelVersion`.
- ⚠️ Model-based routing or metrics using `modelVersion` unreliable.Steps of Reproduction ✅
1. Start a process that imports `pkg/llmproxy/translator` so that `init()` in
`pkg/llmproxy/translator/init.go` runs, registering the Codex→Gemini response translator
via `Register(constant.Gemini, constant.Codex, ..., interfaces.TranslateResponse{Stream:
codexgemini.ConvertCodexResponseToGemini, ...})` in
`pkg/llmproxy/translator/translator/registration.go:159-168`.
2. Issue a streaming request through the Codex executor with a Gemini client format, so
`CodexExecutor.ExecuteStream` in `pkg/llmproxy/executor/codex_executor.go:4-118` is
invoked with `opts.SourceFormat` corresponding to the Gemini format and `req.Model` set to
a Gemini model name such as `"gemini-1.5-pro"`. Inside `ExecuteStream`, `from :=
opts.SourceFormat` and `to := sdktranslator.FromString("codex")` are set (lines 16-18),
and the upstream Codex request body is built.
3. Let the upstream Codex API return SSE lines including a `response.created` event whose
JSON matches the shape used in `TestConvertCodexResponseToGemini`
(`pkg/llmproxy/translator/codex/gemini/codex_gemini_response_test.go:14-16`), for example:
`data: {"type": "response.created", "response": {"id": "resp_123", "model": "gpt-4o"}}`.
`ExecuteStream` scans each line and calls `sdktranslator.TranslateStream(ctx, to, from,
req.Model, originalPayload, body, bytes.Clone(line), ¶m)` at
`pkg/llmproxy/executor/codex_executor.go:100`.
4. `sdk/translator/registry.go:81-88` dispatches this streaming event to the registered
Codex→Gemini transformer, calling `ConvertCodexResponseToGemini(ctx, modelName,
originalRequestRawJSON, requestRawJSON, rawJSON, param)` in
`pkg/llmproxy/translator/codex/gemini/codex_gemini_response.go:42-139`. On first
invocation it initializes `ConvertCodexResponseToGeminiParams{Model: modelName}` (lines
43-49) and sets `modelVersion` from this target model in the non-storage branch via
`template, _ = sjson.SetBytes(template, "modelVersion",
(*param).(*ConvertCodexResponseToGeminiParams).Model)` at line 66. When the `type` is
`"response.created"`, the switch at lines 111-115 executes `template, _ =
sjson.SetBytes(template, "modelVersion", rootResult.Get("response.model").String())` (line
113), overwriting the Gemini target model (e.g., `"gemini-1.5-pro"`) with the upstream
Codex model from the payload (e.g., `"gpt-4o"`). The resulting Gemini-formatted chunk
returned from `ConvertCodexResponseToGemini` (lines 133-139) therefore exposes
`modelVersion: "gpt-4o"` to the Gemini client, while subsequent non-streaming conversions
in `ConvertCodexResponseToGeminiNonStream` (lines 155-190) continue to use the target
`modelName`, creating inconsistent and misleading model identification across responses.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/gemini/codex_gemini_response.go
**Line:** 113:113
**Comment:**
*Logic Error: This overwrites `modelVersion` with the upstream Codex model from the event payload, even though the translator output is Gemini-format and earlier in the same function `modelVersion` is initialized from the target model parameter. This creates inconsistent API contract behavior across events and can mislead downstream clients about which model produced the response.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| out := `{"id":"","type":"message","role":"assistant","model":"","content":[],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"output_tokens":0}}` | ||
| out, _ = sjson.SetBytesM(out, "id", responseData.Get("id").String()) | ||
| out, _ = sjson.SetBytesM(out, "model", responseData.Get("model").String()) | ||
| out := []byte(`{"id":"","type":"message","role":"assistant","model":"","content":[],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"output_tokens":0}}`) |
There was a problem hiding this comment.
Suggestion: This function still returns string, but out was changed to []byte. That breaks the function contract and will fail type-checking at the return path. Keep out as string here, or explicitly convert to string right before returning. [type error]
Severity Level: Critical 🚨
- ❌ Codex→Claude non-stream translator fails compilation.
- ❌ Codex non-stream translation unavailable through ResponseNonStream.
- ⚠️ Unit test TestConvertCodexResponseToClaudeNonStream cannot run.Steps of Reproduction ✅
1. From the repository root `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/codex/claude` to compile
`pkg/llmproxy/translator/codex/claude/codex_claude_response.go`.
2. The compiler loads `ConvertCodexResponseToClaudeNonStream` at
`pkg/llmproxy/translator/codex/claude/codex_claude_response.go:214`, which is declared to
return `string` (verified via Read tool).
3. In the same function, the result buffer is initialized as a byte slice at line `227 out
:= []byte(...)` and later returned directly with `return out` at line `338`, causing a
type mismatch (`[]byte` vs `string`) in this file.
4. Because this function is registered as the Codex→Claude non-stream translator in
`pkg/llmproxy/translator/translator/registration.go:28-37` and plugged into the generic
`ResponseNonStream` adapter in `pkg/llmproxy/translator/translator/translator.go:73-88`,
any build or test that includes this package fails at compile time with a `cannot use out
(variable of type []byte) as type string in return statement` error.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/claude/codex_claude_response.go
**Line:** 227:227
**Comment:**
*Type Error: This function still returns `string`, but `out` was changed to `[]byte`. That breaks the function contract and will fail type-checking at the return path. Keep `out` as `string` here, or explicitly convert to `string` right before returning.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| } | ||
| toolBlock, _ = sjson.SetRaw(toolBlock, "input", inputRaw) | ||
| out, _ = sjson.SetRaw(out, "content.-1", toolBlock) | ||
| toolBlock, _ = sjson.SetRawBytes(toolBlock, "input", inputRaw) |
There was a problem hiding this comment.
Suggestion: sjson.SetRawBytes requires raw JSON bytes for the value argument, but inputRaw is a string. Passing a string to the bytes API is a wrong API contract usage and breaks this conversion path; pass []byte(inputRaw) (after validation) or use the string-based raw setter. [type error]
Severity Level: Critical 🚨
- ❌ Codex→Claude non-stream build fails on type mismatch.
- ❌ Tool-call JSON conversion for non-stream responses unusable.
- ⚠️ Codex tool_use support cannot be exercised in tests.Steps of Reproduction ✅
1. Run `go test ./pkg/llmproxy/translator/codex/claude` from
`/workspace/cliproxyapi-plusplus` to compile
`pkg/llmproxy/translator/codex/claude/codex_claude_response.go`.
2. In `ConvertCodexResponseToClaudeNonStream` at lines `309-320`, the code builds a
tool-use block: `toolBlock := []byte(...)` (line 309), then declares `inputRaw := "{}"`
(string) at line `312`, and conditionally assigns `inputRaw = argsJSON.Raw` (also a
string) at lines `313-316` based on parsed function-call arguments.
3. At line `319`, the code calls `toolBlock, _ = sjson.SetRawBytes(toolBlock, "input",
inputRaw)`, passing `inputRaw` (a `string`) into `sjson.SetRawBytes`, which elsewhere in
this repository is consistently called with `[]byte` values (see e.g.
`pkg/llmproxy/executor/qwen_executor.go:176`,
`pkg/llmproxy/executor/iflow_executor.go:633`, and
`pkg/llmproxy/translator/gemini-cli/openai/chat-completions/gemini-cli_openai_request.go:38`
via Grep).
4. During compilation, the Go type checker reports a mismatch for this call site (`cannot
use inputRaw (variable of type string) as type []byte in argument to sjson.SetRawBytes`)
in `pkg/llmproxy/translator/codex/claude/codex_claude_response.go:319`, preventing
Codex→Claude non-stream responses containing `function_call` items from being built or
used.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/claude/codex_claude_response.go
**Line:** 319:319
**Comment:**
*Type Error: `sjson.SetRawBytes` requires raw JSON bytes for the value argument, but `inputRaw` is a string. Passing a string to the bytes API is a wrong API contract usage and breaks this conversion path; pass `[]byte(inputRaw)` (after validation) or use the string-based raw setter.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
|
||
| if stopSequence := responseData.Get("stop_sequence"); stopSequence.Exists() && stopSequence.String() != "" { | ||
| out, _ = sjson.SetRaw(out, "stop_sequence", stopSequence.Raw) | ||
| out, _ = sjson.SetRawBytes(out, "stop_sequence", stopSequence.Raw) |
There was a problem hiding this comment.
Suggestion: stopSequence.Raw is a string, but this uses SetRawBytes, which expects bytes for raw insertion. This mismatched API call will fail type-checking and prevents setting stop_sequence; convert to bytes or use the string raw setter. [type error]
Severity Level: Critical 🚨
- ❌ Codex→Claude non-stream translator cannot compile successfully.
- ❌ stop_sequence handling for non-stream responses unavailable.
- ⚠️ Downstream callers of ResponseNonStream lose stop_sequence data.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/codex/claude` so that
`pkg/llmproxy/translator/codex/claude/codex_claude_response.go` is compiled as part of the
Codex→Claude translator.
2. In `ConvertCodexResponseToClaudeNonStream`, lines `326-332` determine the stop reason
and assign it into `out` via `sjson.SetBytes`, then at lines `334-335` the code checks
`stopSequence := responseData.Get("stop_sequence")` and uses `stopSequence.Raw` as the
value.
3. At line `335`, the code calls `out, _ = sjson.SetRawBytes(out, "stop_sequence",
stopSequence.Raw)`, passing `stopSequence.Raw` (a `string` from `gjson.Result`) into
`sjson.SetRawBytes`, which in this codebase is otherwise always invoked with `[]byte`
(verified via Grep in `pkg/llmproxy/executor/usage_helpers.go:560-567` and other callers).
4. The Go compiler flags this call as a type error (`cannot use stopSequence.Raw (variable
of type string) as type []byte in argument to sjson.SetRawBytes`) at
`pkg/llmproxy/translator/codex/claude/codex_claude_response.go:335`, blocking successful
compilation of the Codex→Claude non-stream translator and preventing non-stream responses
with `stop_sequence` from building.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/claude/codex_claude_response.go
**Line:** 335:335
**Comment:**
*Type Error: `stopSequence.Raw` is a string, but this uses `SetRawBytes`, which expects bytes for raw insertion. This mismatched API call will fail type-checking and prevents setting `stop_sequence`; convert to bytes or use the string raw setter.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| fnRaw, _ = sjson.SetBytes(fnRaw, "name", name) | ||
| item := []byte(`{}`) | ||
| item, _ = sjson.SetBytes(item, "type", "function") | ||
| item, _ = sjson.SetRawBytes(item, "function", fnRaw) |
There was a problem hiding this comment.
Suggestion: fnRaw is a string, but SetRawBytes expects the raw value as bytes. This is an API contract violation in the tool rewrite logic; convert fnRaw to []byte or switch to string-based SetRaw. [type error]
Severity Level: Critical 🚨
- ❌ Type mismatch in sjson.SetBytes prevents compilation.
- ❌ sjson.SetRawBytes misuse blocks normalizeResponseTools build.
- ❌ Codex responses tool normalization never runs at runtime.Steps of Reproduction ✅
1. Build or test the Codex/OpenAI responses translator package, e.g. run `go test
./pkg/llmproxy/translator/codex/openai/responses`, which compiles
`codex_openai-responses_request.go`.
2. The compiler reaches `normalizeResponseTools` in
`pkg/llmproxy/translator/codex/openai/responses/codex_openai-responses_request.go:171-219`,
where `fnRaw := fn.Raw` is declared at line 200; `fn.Raw` from `github.com/tidwall/gjson`
is a `string`.
3. At line 201, `fnRaw, _ = sjson.SetBytes(fnRaw, "name", name)` attempts to pass `fnRaw`
(a `string`) into `sjson.SetBytes`, whose first parameter is `[]byte`, and to assign the
resulting `[]byte` back into `fnRaw` (still typed as `string`), causing a compile-time
type mismatch before this function can succeed.
4. Even if the prior line were fixed, at line 204 `item, _ = sjson.SetRawBytes(item,
"function", fnRaw)` would still pass `fnRaw` as a `string` into `sjson.SetRawBytes` (which
expects a `[]byte` for the raw payload), producing another compile-time error and
preventing the Codex→OpenAI Responses normalization path (registered in
`pkg/llmproxy/translator/translator/registration.go:195-201`) from building.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/openai/responses/codex_openai-responses_request.go
**Line:** 204:204
**Comment:**
*Type Error: `fnRaw` is a string, but `SetRawBytes` expects the raw value as bytes. This is an API contract violation in the tool rewrite logic; convert `fnRaw` to `[]byte` or switch to string-based `SetRaw`.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| out := "[]" | ||
| for _, item := range result { | ||
| out, _ = sjson.SetRaw(out, "-1", item) | ||
| out, _ = sjson.SetRawBytes(out, "-1", item) |
There was a problem hiding this comment.
Suggestion: The accumulator out is a string ("[]"), but this calls SetRawBytes, which is the bytes-only API. This type mismatch breaks reconstruction of the tools array; use SetRaw for string buffers or migrate out to []byte consistently. [type error]
Severity Level: Critical 🚨
- ❌ normalizeResponseTools cannot compile due to type mismatch.
- ❌ Tools array normalization for Codex Responses never runs.
- ❌ Codex→OpenAI Responses translation path unusable until fixed.Steps of Reproduction ✅
1. Invoke a build of the translator packages, e.g. `go test
./pkg/llmproxy/translator/codex/openai/responses`, which compiles
`codex_openai-responses_request.go`.
2. In `normalizeResponseTools`
(`pkg/llmproxy/translator/codex/openai/responses/codex_openai-responses_request.go:171-219`),
the accumulator `out` is initialized as a Go string at line 215: `out := "[]"`.
3. At line 217, the code calls `out, _ = sjson.SetRawBytes(out, "-1", item)`, passing
`out` (a `string`) to `sjson.SetRawBytes`, which expects its first parameter (`dst`) to be
a `[]byte` and returns a `[]byte`.
4. This leads to a compile-time error ("cannot use out (variable of type string) as []byte
value" and incompatible assignment of `[]byte` to `string`), preventing the tools array
reconstruction in `normalizeResponseTools` and blocking the Codex→OpenAI Responses
translator registered in `pkg/llmproxy/translator/translator/registration.go:195-201` from
compiling.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/openai/responses/codex_openai-responses_request.go
**Line:** 217:217
**Comment:**
*Type Error: The accumulator `out` is a string (`"[]"`), but this calls `SetRawBytes`, which is the bytes-only API. This type mismatch breaks reconstruction of the `tools` array; use `SetRaw` for string buffers or migrate `out` to `[]byte` consistently.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| // Build output Gemini CLI request JSON | ||
| out := `{"contents":[]}` | ||
| out, _ = sjson.SetBytesM(out, "model", modelName) | ||
| out, _ = sjson.SetBytes(out, "model", modelName) |
There was a problem hiding this comment.
Suggestion: out is a string buffer in this function, but sjson.SetBytes is the byte-buffer API. Using it with a string accumulator is an API contract mismatch that causes compilation/type failures. Use the string API (sjson.Set) or switch the accumulator to []byte consistently. [type error]
Severity Level: Critical 🚨
- ❌ `go build ./...` fails in translator/gemini/claude package.
- ⚠️ Gemini Claude translator unusable due to compilation error.Steps of Reproduction ✅
1. Apply this PR and run `go build ./...` from the repo root so that package
`pkg/llmproxy/translator/gemini/claude` is compiled.
2. The Go compiler processes `ConvertClaudeRequestToGemini` in
`pkg/llmproxy/translator/gemini/claude/gemini_claude_request.go:30-203`.
3. At line 36 (`out, _ = sjson.SetBytes(out, "model", modelName)`), the compiler sees
`out` declared as a string at line 35 (`out := {"contents":[]}`) while `sjson.SetBytes`
expects a `[]byte` input and returns `[]byte`.
4. Compilation fails with a type mismatch error (string used where `[]byte` is required),
preventing the `pkg/llmproxy/translator/gemini/claude` package and any dependents from
building.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/claude/gemini_claude_request.go
**Line:** 36:36
**Comment:**
*Type Error: `out` is a string buffer in this function, but `sjson.SetBytes` is the byte-buffer API. Using it with a string accumulator is an API contract mismatch that causes compilation/type failures. Use the string API (`sjson.Set`) or switch the accumulator to `[]byte` consistently.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| part, _ = sjson.SetBytesM(part, "functionResponse.name", funcName) | ||
| part, _ = sjson.SetBytesM(part, "functionResponse.response.result", responseData) | ||
| part, _ = sjson.SetBytes(part, "functionResponse.name", funcName) | ||
| part, _ = sjson.SetBytes(part, "functionResponse.response.result", responseData) |
There was a problem hiding this comment.
Suggestion: responseData is taken from .Raw and may already be JSON (object/array/string literal), but sjson.SetBytes will write it as a JSON string value, double-encoding structured tool output. This can break function-result semantics for Gemini tool responses. Write raw JSON when valid (raw setter) and only fall back to string setter when it is not valid JSON. [logic error]
Severity Level: Critical 🚨
- ❌ Gemini tool_result responses mis-encoded, breaking functionResponse.result payload.
- ⚠️ Downstream consumers receive stringified JSON instead of structured result.Steps of Reproduction ✅
1. Build the project so that `ConvertClaudeRequestToGemini` in
`pkg/llmproxy/translator/gemini/claude/gemini_claude_request.go:30-203` is available and
used by the Gemini/Claude translator pipeline.
2. Send a Claude-style request into the translator that includes a
`messages[].content[].type == "tool_result"` entry whose `content` field is structured
JSON (e.g., an object like `{"foo":"bar"}`), so that the `tool_result` branch at lines
109-123 is exercised.
3. Inside the `tool_result` branch, at line 119, `responseData :=
contentResult.Get("content").Raw` captures the raw JSON string representation (e.g.,
`{"foo":"bar"}`) of the tool result payload.
4. At line 122, `part, _ = sjson.SetBytes(part, "functionResponse.response.result",
responseData)` writes this raw JSON string as a JSON string value, resulting in
`"result":"{\"foo\":\"bar\"}"` instead of `"result":{"foo":"bar"}`, so Gemini receives a
stringified JSON payload instead of the intended structured result, breaking tool response
semantics.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/claude/gemini_claude_request.go
**Line:** 122:122
**Comment:**
*Logic Error: `responseData` is taken from `.Raw` and may already be JSON (object/array/string literal), but `sjson.SetBytes` will write it as a JSON string value, double-encoding structured tool output. This can break function-result semantics for Gemini tool responses. Write raw JSON when valid (raw setter) and only fall back to string setter when it is not valid JSON.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| // from OpenAI function schema inputs and enforces a deterministic root shape. | ||
| func NormalizeOpenAIFunctionSchemaForGemini(params gjson.Result, strict bool) string { | ||
| out := `{"type":"OBJECT","properties":{}}` | ||
| out := []byte(`{"type":"OBJECT","properties":{}}`) |
There was a problem hiding this comment.
Suggestion: out is initialized as []byte, but this function's contract and existing flow are string-based (NormalizeOpenAIFunctionSchemaForGemini(... ) string). This type shift causes downstream assignments/returns in this function to become incompatible and breaks the package build. Keep out as a string (or convert the whole function signature and callers consistently). [type error]
Severity Level: Critical 🚨
- ❌ Gemini common sanitizer package fails to compile.
- ❌ Gemini OpenAI chat-completions translator build is blocked.
- ❌ Gemini OpenAI responses translator package cannot be built.Steps of Reproduction ✅
1. Run `go test ./pkg/llmproxy/translator/gemini/common` from the repository root
(`/workspace/cliproxyapi-plusplus`), which compiles
`pkg/llmproxy/translator/gemini/common/sanitize.go`.
2. During compilation, the Go compiler processes `NormalizeOpenAIFunctionSchemaForGemini`
at `sanitize.go:44-62`, where `out` is declared as `[]byte` at line 45 and
`SanitizeParametersJSONSchemaForGemini` returns `string` at lines 25–28; the assignment
`out = SanitizeParametersJSONSchemaForGemini(raw)` at line 52 fails with a type mismatch
(`cannot use string as type []byte in assignment`).
3. In the same function, the final `return out` at line 62 attempts to return a `[]byte`
from a function declared to return `string` (`func
NormalizeOpenAIFunctionSchemaForGemini(... ) string` at line 44), producing an additional
compile-time error.
4. Because of these type errors, dependent packages such as
`pkg/llmproxy/translator/gemini/openai/chat-completions/gemini_openai_request.go` (using
`schema := common.NormalizeOpenAIFunctionSchemaForGemini(...)` at lines 31–36) and
`pkg/llmproxy/translator/gemini/openai/responses/gemini_openai-responses_request.go`
(using `cleaned := common.NormalizeOpenAIFunctionSchemaForGemini(...)` at lines 390–415)
fail to compile as part of any `go build ./...` or `go test ./...` run.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/common/sanitize.go
**Line:** 45:45
**Comment:**
*Type Error: `out` is initialized as `[]byte`, but this function's contract and existing flow are string-based (`NormalizeOpenAIFunctionSchemaForGemini(... ) string`). This type shift causes downstream assignments/returns in this function to become incompatible and breaks the package build. Keep `out` as a string (or convert the whole function signature and callers consistently).
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| one := `{"role":"","parts":[{"text":""}]}` | ||
| one, _ = sjson.SetBytesM(one, "role", effRole) | ||
| one, _ = sjson.SetBytesM(one, "parts.0.text", contentText) | ||
| one, _ = sjson.SetBytes(one, "role", effRole) |
There was a problem hiding this comment.
Suggestion: one is created as a string JSON template, but sjson.SetBytes expects a byte slice JSON buffer. This mismatch causes compile-time type errors in this branch. Use sjson.Set for string buffers or convert one to []byte and keep byte APIs throughout. [type error]
Severity Level: Critical 🚨
- ❌ pkg/llmproxy/translator package fails to build due type-error.
- ❌ OpenAI Responses→Gemini translation unavailable via translator registration.Steps of Reproduction ✅
1. From the repo root, run `go test ./pkg/llmproxy/translator/...` or `go build
./pkg/llmproxy/translator/...` to compile the translator packages, which include
`pkg/llmproxy/translator/gemini/openai/responses`.
2. During compilation, Go loads `pkg/llmproxy/translator/translator/registration.go` where
`ConvertOpenAIResponsesRequestToGemini` is registered as a translator at lines 253–256
(`geminiopenairesponses.ConvertOpenAIResponsesRequestToGemini`), forcing
`pkg/llmproxy/translator/gemini/openai/responses` to be compiled.
3. The compiler type-checks `ConvertOpenAIResponsesRequestToGemini` in
`pkg/llmproxy/translator/gemini/openai/responses/gemini_openai-responses_request.go:14+`
and reaches the branch for `contentArray.Type == gjson.String` where `one` is declared as
a string at line 293 (`one := {"role":"","parts":[{"text":""}]}`) and then passed to
`sjson.SetBytes` at line 294 (`one, _ = sjson.SetBytes(one, "role", effRole)`).
4. Because `sjson.SetBytes`' first parameter is `[]byte` while `one` is a `string`, the Go
compiler emits a type error like `cannot use one (variable of type string) as []byte value
in argument to sjson.SetBytes` at `gemini_openai-responses_request.go:294`, causing
`pkg/llmproxy/translator/gemini/openai/responses` (and thus `pkg/llmproxy/translator`) to
fail to build.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini/openai/responses/gemini_openai-responses_request.go
**Line:** 294:294
**Comment:**
*Type Error: `one` is created as a string JSON template, but `sjson.SetBytes` expects a byte slice JSON buffer. This mismatch causes compile-time type errors in this branch. Use `sjson.Set` for string buffers or convert `one` to `[]byte` and keep byte APIs throughout.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
CodeAnt AI finished reviewing your PR. |
Repairs deep symbol drift in pkg/llmproxy/auth/kiro/ so the package compiles cleanly against current main (after #956 + #958 merged). Changes: - pkg/llmproxy/config/config.go: add KiroFingerprintConfig type and Config.KiroFingerprint field so application config can override the randomized fingerprint identity used by the kiro FingerprintManager. - pkg/llmproxy/auth/kiro/fingerprint.go: add FingerprintConfig type, process-wide SetGlobalFingerprintConfig / GetGlobalFingerprintConfig helpers, and a GlobalFingerprintManager() function-form alias for callers (e.g. social_auth.go) that use that spelling instead of GetGlobalFingerprintManager. - pkg/llmproxy/auth/kiro/sso_oidc.go: update three FetchUserEmailWithFallback call sites to pass clientID (regResp.ClientID) and refreshToken (tokenResp.RefreshToken), matching the current 5-arg signature. - pkg/llmproxy/auth/kiro/runtime_helpers.go: wire FetchProfileArn to warm the per-account fingerprint via GetAccountKey(clientID, refreshToken) before delegating to fetchProfileArn, so subsequent runtime calls (setRuntimeHeaders) reuse a consistent fingerprint for the account. - pkg/llmproxy/auth/kiro/codewhisperer_client.go: drop unused github.com/google/uuid import. - pkg/llmproxy/auth/kiro/token.go: drop unused pkg/llmproxy/auth/base import. Verification: go build ./pkg/llmproxy/auth/kiro/... # clean Out of scope (still failing on main, not touched here): - pkg/llmproxy/translator/openai/claude/... - pkg/llmproxy/translator/openai/gemini-cli/... - pkg/llmproxy/translator/claude/gemini-cli/... - sdk/auth/{codex,kiro,errors}.go Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
CodeAnt AI is running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
size:XL
| return fmt.Errorf("git token store: create repo dir: %w", errMk) | ||
| } | ||
| if _, errClone := git.PlainClone(repoDir, &git.CloneOptions{Auth: authMethod, URL: s.remote}); errClone != nil { | ||
| if _, errClone := git.PlainClone(repoDir, &git.CloneOptions{ClientOptions: authMethod, URL: s.remote}); errClone != nil { |
There was a problem hiding this comment.
Suggestion: Refactor the repository bootstrapping and clone/error-handling branch into one or more helper methods so this modified function stays under the 40-line limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The updated EnsureRepository function is clearly far longer than the 40-line limit, with the clone/error-handling branch embedded in a large block of setup logic. The suggestion correctly identifies a real custom-rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/store/gitstore.go
**Line:** 124:124
**Comment:**
*Custom Rule: Refactor the repository bootstrapping and clone/error-handling branch into one or more helper methods so this modified function stays under the 40-line limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| } | ||
| s.maybeRunGC(repo) | ||
| if err = repo.Push(&git.PushOptions{Auth: s.gitAuth(), Force: true}); err != nil { | ||
| if err = repo.Push(&git.PushOptions{ClientOptions: s.gitAuth(), Force: true}); err != nil { |
There was a problem hiding this comment.
Suggestion: Extract the push/rewrite/GC sequence into a dedicated helper to keep this modified commit flow function within the 40-line maximum. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The commitAndPushLocked function is well over 40 lines long, and the push/rewrite/GC sequence is part of that oversized workflow. This is a real violation of the custom line-limit rule, so the suggestion is valid.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/store/gitstore.go
**Line:** 645:645
**Comment:**
*Custom Rule: Extract the push/rewrite/GC sequence into a dedicated helper to keep this modified commit flow function within the 40-line maximum.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| tool := []byte(toolResult.Raw) | ||
| tool, _ = sjson.SetBytes(tool, "type", "function") |
There was a problem hiding this comment.
Suggestion: Refactor the tool-conversion logic into a separate helper function (including custom-tool handling and type normalization) so the modified function body no longer exceeds the 40-line limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The final file still contains a very large ConvertClaudeRequestToCodex function, and the tool-conversion section is part of that oversized body. The suggestion to extract this logic into a helper is consistent with the stated 40-line limit rule, so this is a real violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/codex/claude/codex_claude_request.go
**Line:** 281:282
**Comment:**
*Custom Rule: Refactor the tool-conversion logic into a separate helper function (including custom-tool handling and type normalization) so the modified function body no longer exceeds the 40-line limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| // Build output Gemini CLI request JSON | ||
| out := `{"model":"","request":{"contents":[]}}` | ||
| out, _ = sjson.SetBytesM(out, "model", modelName) | ||
| out, _ = sjson.SetBytes(out, "model", modelName) |
There was a problem hiding this comment.
Suggestion: Refactor this modified function by extracting major sections (for example, system-instruction mapping, message/content mapping, tool mapping, and generation-config mapping) into helper functions so the main function body stays under the 40-line limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The suggestion is consistent with a real rule violation: the updated function is very large and combines several distinct responsibilities in one body (system mapping, content mapping, tool mapping, and generation config mapping). That exceeds the stated 40-line limit for the modified function body, so the suggestion is verified.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini-cli/claude/gemini-cli_claude_request.go
**Line:** 43:43
**Comment:**
*Custom Rule: Refactor this modified function by extracting major sections (for example, system-instruction mapping, message/content mapping, tool mapping, and generation-config mapping) into helper functions so the main function body stays under the 40-line limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Sequence DiagramThis diagram shows how the restored Kiro runtime helpers connect the OAuth-based AWS login to usage quota checks by deriving a region-specific runtime endpoint and fingerprinted headers from the profile ARN and account key before calling the usage limits API. sequenceDiagram
participant User
participant OAuthWebHandler
participant AWSSSO
participant KiroUsageClient
participant AWSRuntime
User->>OAuthWebHandler: Start device authorization
OAuthWebHandler->>AWSSSO: Exchange device code for access token and profile ARN
AWSSSO-->>OAuthWebHandler: Token and profile ARN
OAuthWebHandler->>OAuthWebHandler: Persist token data including profile ARN
User->>KiroUsageClient: Check usage with stored token data
KiroUsageClient->>KiroUsageClient: Derive region endpoint and account key
KiroUsageClient->>AWSRuntime: GET usage limits with fingerprint headers
AWSRuntime-->>KiroUsageClient: Usage quota response
KiroUsageClient-->>User: Remaining quota status
Generated by CodeAnt AI |
| promptTokenCount := usageResult.Get("promptTokenCount").Int() | ||
| thoughtsTokenCount := usageResult.Get("thoughtsTokenCount").Int() | ||
| template, _ = sjson.SetBytesM(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) | ||
| template, _ = sjson.SetBytes(template, "usage.prompt_tokens", promptTokenCount+thoughtsTokenCount) |
There was a problem hiding this comment.
Suggestion: ConvertCliResponseToOpenAI is a modified function and its body is far beyond 40 lines; extract the usage-metadata handling (including this assignment) into a small helper to keep the function within the size rule. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The suggestion matches a real rule violation: ConvertCliResponseToOpenAI is a large function well over 40 lines, and this usage-metadata logic is part of that oversized body. The code shown is exactly the assignment the suggestion calls out, so the violation is present in the final file state.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini-cli/openai/chat-completions/gemini-cli_openai_response.go
**Line:** 108:108
**Comment:**
*Custom Rule: `ConvertCliResponseToOpenAI` is a modified function and its body is far beyond 40 lines; extract the usage-metadata handling (including this assignment) into a small helper to keep the function within the size rule.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| contentBlockStartJSON := []byte(`{"type":"content_block_start","index":0,"content_block":{"type":"thinking","thinking":""}}`) | ||
| contentBlockStartJSON, _ = sjson.SetBytes(contentBlockStartJSON, "index", param.ThinkingContentBlockIndex) |
There was a problem hiding this comment.
Suggestion: This function is already far beyond the 40-line limit; extract the newly added reasoning/content block JSON assembly into a dedicated helper to reduce function size and keep the main flow readable. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The modified streaming conversion function is far longer than 40 lines in the final file, and this snippet is part of the newly added inline JSON assembly contributing to that excess. The suggestion correctly identifies a real function-length rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/openai/claude/openai_claude_response.go
**Line:** 193:194
**Comment:**
*Custom Rule: This function is already far beyond the 40-line limit; extract the newly added reasoning/content block JSON assembly into a dedicated helper to reduce function size and keep the main flow readable.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| inputDeltaJSON := []byte(`{"type":"content_block_delta","index":0,"delta":{"type":"input_json_delta","partial_json":""}}`) | ||
| inputDeltaJSON, _ = sjson.SetBytes(inputDeltaJSON, "index", blockIndex) | ||
| inputDeltaJSON, _ = sjson.SetBytes(inputDeltaJSON, "delta.partial_json", util.FixJSON(accumulator.Arguments.String())) |
There was a problem hiding this comment.
Suggestion: The modified function now exceeds the 40-line threshold; move the added tool-call finalization payload generation into a small helper to keep this function under the rule limit. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The streaming conversion function is clearly well over the 40-line limit in the final file, and this added tool-call finalization payload is part of the inline growth. The suggestion accurately matches a real custom-rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/openai/claude/openai_claude_response.go
**Line:** 326:328
**Comment:**
*Custom Rule: The modified function now exceeds the 40-line threshold; move the added tool-call finalization payload generation into a small helper to keep this function under the rule limit.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| out := []byte(`{"id":"","type":"message","role":"assistant","model":"","content":[],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"output_tokens":0}}`) | ||
| out, _ = sjson.SetBytes(out, "id", root.Get("id").String()) | ||
| out, _ = sjson.SetBytes(out, "model", root.Get("model").String()) |
There was a problem hiding this comment.
Suggestion: This modified non-stream conversion function is over the 40-line limit; extract the added output-initialization and payload-building responsibilities into helper functions. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The non-stream conversion function is also far longer than 40 lines in the final file. This newly added output initialization is part of that overlength function, so the suggestion identifies a real rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/openai/claude/openai_claude_response.go
**Line:** 427:429
**Comment:**
*Custom Rule: This modified non-stream conversion function is over the 40-line limit; extract the added output-initialization and payload-building responsibilities into helper functions.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| } | ||
| partJSON := `{}` | ||
| partJSON, _ = sjson.SetBytesM(partJSON, "text", systemPrompt) | ||
| partJSON, _ = sjson.SetBytes(partJSON, "text", systemPrompt) |
There was a problem hiding this comment.
Suggestion: sjson.SetBytes expects a byte-slice JSON buffer, but this call passes a string buffer, which breaks the sjson API contract and will fail type-checking. Keep this value as []byte (or use the string-based sjson API consistently) before setting fields. [type error]
Severity Level: Critical 🚨
- ❌ Antigravity Claude translator package fails to compile.
- ⚠️ Tests for antigravity Claude translator cannot run.Steps of Reproduction ✅
1. From the repository root `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/antigravity/claude` which builds the `claude` package containing
`ConvertClaudeRequestToAntigravity` (see
`pkg/llmproxy/translator/antigravity/claude/antigravity_claude_request_test.go:11,27`).
2. The Go toolchain compiles
`pkg/llmproxy/translator/antigravity/claude/antigravity_claude_request.go`, where at lines
58–60 the system-instruction loop initializes `partJSON := \`{}\`` (line 58) as a string
and then calls `partJSON, _ = sjson.SetBytes(partJSON, "text", systemPrompt)` (line 59).
3. Because `github.com/tidwall/sjson` is imported at lines 16–17 and its `SetBytes` API
expects a `[]byte` as the first parameter, the compiler reports a type mismatch:
`partJSON` is a `string` at line 58, so it cannot be passed to `sjson.SetBytes` which
requires `[]byte`, causing a compile-time error in this package.
4. The build of `pkg/llmproxy/translator/antigravity/claude` fails, so the entire `go test
./pkg/llmproxy/translator/antigravity/claude` invocation (and any broader `go test ./...`
or `go build ./...` including this package) is blocked before any tests or runtime paths
for `ConvertClaudeRequestToAntigravity` can execute.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/antigravity/claude/antigravity_claude_request.go
**Line:** 59:59
**Comment:**
*Type Error: `sjson.SetBytes` expects a byte-slice JSON buffer, but this call passes a string buffer, which breaks the sjson API contract and will fail type-checking. Keep this value as `[]byte` (or use the string-based sjson API consistently) before setting fields.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| contentPart = `{"type":"image","source":{"type":"base64","media_type":"","data":""}}` | ||
| contentPart, _ = sjson.SetBytesM(contentPart, "source.media_type", mediaType) | ||
| contentPart, _ = sjson.SetBytesM(contentPart, "source.data", data) | ||
| contentPart = []byte(`{"type":"image","source":{"type":"base64","media_type":"","data":""}}`) |
There was a problem hiding this comment.
Suggestion: This assigns a []byte literal into a variable declared as string, which is a direct type mismatch and breaks the conversion flow in image-part handling. Keep contentPart consistently typed (all string or all []byte) throughout this block. [type error]
Severity Level: Critical 🚨
- ❌ Responses translator package fails to compile on go build.
- ⚠️ Image input handling cannot be exercised or deployed.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/responses`.
2. Go compiles
`pkg/llmproxy/translator/claude/openai/responses/claude_openai-responses_request.go`,
which defines `ConvertOpenAIResponsesRequestToClaude` at line 33.
3. In the `"message"` type handling inside `ConvertOpenAIResponsesRequestToClaude`, the
`"input_image"` branch declares `var contentPart string` at line 192 and later assigns
`contentPart = []byte(...)` at line 205.
4. The compiler reports a type error like `cannot use []byte(...) (value of type []byte)
as type string in assignment` at `claude_openai-responses_request.go:205`, causing the
`responses` package (and tests like `TestConvertOpenAIResponsesRequestToClaude` in
`claude_openai-responses_request_test.go:9`) not to build.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/responses/claude_openai-responses_request.go
**Line:** 205:205
**Comment:**
*Type Error: This assigns a `[]byte` literal into a variable declared as `string`, which is a direct type mismatch and breaks the conversion flow in image-part handling. Keep `contentPart` consistently typed (all string or all []byte) throughout this block.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| } else { | ||
| for _, partJSON := range partsJSON { | ||
| msg, _ = sjson.SetRaw(msg, "content.-1", partJSON) | ||
| msg, _ = sjson.SetRawBytes(msg, "content.-1", partJSON) |
There was a problem hiding this comment.
Suggestion: partJSON elements are strings, but this uses SetRawBytes which requires raw JSON bytes, causing an API/type mismatch at message assembly time. Use SetRaw for string raw fragments or convert partsJSON to byte slices consistently. [type error]
Severity Level: Critical 🚨
- ❌ Message assembly code for responses translator fails compilation.
- ⚠️ Mixed text/image messages cannot be built or tested.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/responses`.
2. During compilation of `ConvertOpenAIResponsesRequestToClaude` in
`claude_openai-responses_request.go`, the `"message"` handling branch declares `var
partsJSON []string` at line 166 and populates it with JSON fragments.
3. In the multi-part path (no legacy flattening), the loop `for _, partJSON := range
partsJSON` at lines 264–266 calls `msg, _ = sjson.SetRawBytes(msg, "content.-1",
partJSON)` where `msg` is `[]byte` and `partJSON` has type `string`.
4. Because `sjson.SetRawBytes` expects its third argument to be `[]byte`, the compiler
emits `cannot use partJSON (variable of type string) as []byte value in argument to
sjson.SetRawBytes` at line 265, preventing the responses translator package and its tests
from building (even after fixing earlier type errors).Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/responses/claude_openai-responses_request.go
**Line:** 265:265
**Comment:**
*Type Error: `partJSON` elements are strings, but this uses `SetRawBytes` which requires raw JSON bytes, causing an API/type mismatch at message assembly time. Use `SetRaw` for string raw fragments or convert `partsJSON` to byte slices consistently.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| }) | ||
| if gjson.Parse(toolsJSON).IsArray() && len(gjson.Parse(toolsJSON).Array()) > 0 { | ||
| out, _ = sjson.SetRaw(out, "tools", toolsJSON) | ||
| out, _ = sjson.SetRawBytes(out, "tools", toolsJSON) |
There was a problem hiding this comment.
Suggestion: toolsJSON is built as a string, but SetRawBytes expects a byte-slice payload, so this violates the API contract when wiring tools into the output request. Either keep toolsJSON as []byte during construction or switch this call to SetRaw. [type error]
Severity Level: Critical 🚨
- ❌ Tools mapping prevents responses translator from compiling.
- ⚠️ Tool-enabled Claude requests cannot be exercised in tests.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/responses`.
2. The compiler processes the tools mapping block in
`ConvertOpenAIResponsesRequestToClaude` (lines 334–357) in
`claude_openai-responses_request.go`, where `toolsJSON := "[]"` is declared as a `string`
and built via `sjson.SetRaw` calls.
3. When the tools array is non-empty, line 356 executes `out, _ = sjson.SetRawBytes(out,
"tools", toolsJSON)` where `out` is `[]byte` and `toolsJSON` is `string`.
4. Since `sjson.SetRawBytes` requires its raw JSON argument to be `[]byte`, Go reports
`cannot use toolsJSON (variable of type string) as []byte value in argument to
sjson.SetRawBytes`, stopping compilation of the responses translator and preventing tests
like `TestConvertOpenAIResponsesRequestToClaudeToolChoice` from running.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/responses/claude_openai-responses_request.go
**Line:** 356:356
**Comment:**
*Type Error: `toolsJSON` is built as a string, but `SetRawBytes` expects a byte-slice payload, so this violates the API contract when wiring tools into the output request. Either keep `toolsJSON` as `[]byte` during construction or switch this call to `SetRaw`.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| switch toolChoice.String() { | ||
| case "auto": | ||
| out, _ = sjson.SetRaw(out, "tool_choice", `{"type":"auto"}`) | ||
| out, _ = sjson.SetRawBytes(out, "tool_choice", `{"type":"auto"}`) |
There was a problem hiding this comment.
Suggestion: SetRawBytes requires raw JSON bytes, but this call passes a string literal, creating a type mismatch in tool-choice mapping. Pass a byte slice or use the string-based raw setter. [type error]
Severity Level: Critical 🚨
- ❌ Tool_choice mapping causes compilation failure in translator.
- ⚠️ OpenAI tool_choice translation cannot be tested or deployed.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/responses`.
2. In `ConvertOpenAIResponsesRequestToClaude`'s tool_choice mapping (lines 360–371) in
`claude_openai-responses_request.go`, the `"auto"` case calls `out, _ =
sjson.SetRawBytes(out, "tool_choice", {"type":"auto"})` and the `"required"` case uses a
similar `SetRawBytes` call.
3. Both calls pass a string literal as the third argument to `sjson.SetRawBytes`, whose
signature requires a `[]byte` raw JSON payload.
4. The compiler therefore raises a type error such as `cannot use "{\"type\":\"auto\"}"
(untyped string constant) as []byte value in argument to sjson.SetRawBytes`, breaking the
build of the responses translator and preventing tool_choice translation from being
exercised (e.g., in `TestConvertOpenAIResponsesRequestToClaudeToolChoice` at
`claude_openai-responses_request_test.go:41`).Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/responses/claude_openai-responses_request.go
**Line:** 366:366
**Comment:**
*Type Error: `SetRawBytes` requires raw JSON bytes, but this call passes a string literal, creating a type mismatch in tool-choice mapping. Pass a byte slice or use the string-based raw setter.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| part := []byte(`{"type":"redacted_thinking","data":""}`) | ||
| part, _ = sjson.SetBytes(part, "data", text) |
There was a problem hiding this comment.
Suggestion: This function returns string, but the local value was changed to []byte; downstream callers treat this helper as returning a string raw fragment, so this introduces a return-type inconsistency. Keep this builder as string-based (or update signature and all call sites together). [type error]
Severity Level: Critical 🚨
- ❌ Reasoning redaction helper fails type-check, blocking compilation.
- ⚠️ Thinking-enabled responses cannot be translated to Claude format.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/responses`.
2. The compiler parses the helper `buildRedactedThinkingPart` at the end of
`claude_openai-responses_request.go` with signature `func buildRedactedThinkingPart(text
string) string` (around lines 449–53).
3. Inside this function, `part` is declared as `[]byte` and then returned directly in
`return part`, conflicting with the declared `string` return type.
4. Go emits a compile-time error like `cannot use part (variable of type []byte) as string
value in return statement`, and since `buildRedactedThinkingPart` is used by
`redactedThinkingPartFromResult` and the `"reasoning"`/thinking paths in
`ConvertOpenAIResponsesRequestToClaude` (e.g., lines 248, 297, 330), the entire responses
translator package fails to compile.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/responses/claude_openai-responses_request.go
**Line:** 450:451
**Comment:**
*Type Error: This function returns `string`, but the local value was changed to `[]byte`; downstream callers treat this helper as returning a string raw fragment, so this introduces a return-type inconsistency. Keep this builder as string-based (or update signature and all call sites together).
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| argsJSON := gjson.Parse(argsStr) | ||
| if argsJSON.IsObject() { | ||
| toolUse, _ = sjson.SetRaw(toolUse, "input", argsJSON.Raw) | ||
| toolUse, _ = sjson.SetRawBytes(toolUse, "input", argsJSON.Raw) |
There was a problem hiding this comment.
Suggestion: SetRawBytes is being called with argsJSON.Raw (a string), which can fail raw insertion in byte-buffer mode and leave the tool input unset/defaulted when errors are ignored. Convert the raw JSON string to bytes before calling the raw-bytes API so tool arguments are preserved. [logic error]
Severity Level: Critical 🚨
- ❌ Chat-completions translator package fails to build.
- ❌ Kiro Claude payload compatibility tests cannot run.
- ⚠️ Chat tools arguments mapping unavailable for any runtime use.Steps of Reproduction ✅
1. From the repo root `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/chat-completions` to compile
`ConvertOpenAIRequestToClaude` and its tests
(`pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request_test.go:9-24`).
2. The compiler processes `ConvertOpenAIRequestToClaude` in
`pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request.go:45-315`,
which imports `github.com/tidwall/sjson` at lines 18-19 and uses `sjson.SetRawBytes`
elsewhere in the codebase with `[]byte` values (e.g., `sjson.SetRawBytes(body, "tools",
[]byte(placeholder))` in `pkg/llmproxy/executor/iflow_executor.go:633`).
3. At `claude_openai_request.go:221-227`, the compiler reaches the tool-call handling
block and encounters `toolUse, _ = sjson.SetRawBytes(toolUse, "input", argsJSON.Raw)` on
line 227, where `argsJSON.Raw` is a `string` from `gjson.Result` (constructed at lines
223-226).
4. Because `sjson.SetRawBytes` from `github.com/tidwall/sjson` expects a `[]byte` third
parameter, the Go compiler reports a type error such as "cannot use argsJSON.Raw (variable
of type string) as type []byte in argument to sjson.SetRawBytes", preventing this package
(and downstream tests like `translator/kiro/claude/kiro_claude_request_test.go:19-24`)
from building; the runtime scenario of silently dropped tool inputs cannot occur because
the code never compiles.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request.go
**Line:** 227:227
**Comment:**
*Logic Error: `SetRawBytes` is being called with `argsJSON.Raw` (a string), which can fail raw insertion in byte-buffer mode and leave the tool `input` unset/defaulted when errors are ignored. Convert the raw JSON string to bytes before calling the raw-bytes API so tool arguments are preserved.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| // Convert parameters schema for the tool | ||
| if parameters := function.Get("parameters"); parameters.Exists() { | ||
| anthropicTool, _ = sjson.SetRaw(anthropicTool, "input_schema", parameters.Raw) | ||
| anthropicTool, _ = sjson.SetRawBytes(anthropicTool, "input_schema", parameters.Raw) |
There was a problem hiding this comment.
Suggestion: The tool schema is injected via SetRawBytes using parameters.Raw directly (string), which can fail raw insertion and silently omit input_schema because the returned error is discarded. Pass bytes to the byte raw setter to ensure schema propagation works. [logic error]
Severity Level: Critical 🚨
- ❌ Tools-schema mapping code prevents package compilation.
- ❌ OpenAI tools cannot be translated to Claude format.
- ⚠️ Kiro integration tests depending on tools cannot execute.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/chat-completions` to build the OpenAI→Claude
translator and its tests.
2. The compiler processes the tools mapping block in
`pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request.go:262-283`,
which builds `anthropicTool` JSON and then calls `sjson.SetRawBytes` to set the
`input_schema` field.
3. At line 274, it encounters `anthropicTool, _ = sjson.SetRawBytes(anthropicTool,
"input_schema", parameters.Raw)`, where `parameters` is a `gjson.Result` and
`parameters.Raw` is a `string`, while `sjson.SetRawBytes` (as used consistently elsewhere,
e.g., `sjson.SetRawBytes(cleaned, "cpaUsageMetadata", []byte(usageMetadata.Raw))` in
`pkg/llmproxy/executor/usage_helpers.go:560-567`) expects a `[]byte` third argument.
4. This string-versus-[]byte mismatch causes a compile-time error for this package,
blocking any execution of `ConvertOpenAIRequestToClaude` in tests
(`claude_openai_request_test.go:9-24`) or indirect callers like the Kiro translator tests
(`translator/kiro/claude/kiro_claude_request_test.go:19-24`); therefore, the described
runtime omission of `input_schema` never occurs because the code cannot be built.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request.go
**Line:** 274:274
**Comment:**
*Logic Error: The tool schema is injected via `SetRawBytes` using `parameters.Raw` directly (string), which can fail raw insertion and silently omit `input_schema` because the returned error is discarded. Pass bytes to the byte raw setter to ensure schema propagation works.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| // Don't set tool_choice, Claude Code will not use tools | ||
| case "auto": | ||
| out, _ = sjson.SetRaw(out, "tool_choice", `{"type":"auto"}`) | ||
| out, _ = sjson.SetRawBytes(out, "tool_choice", `{"type":"auto"}`) |
There was a problem hiding this comment.
Suggestion: Raw tool-choice JSON is set through SetRawBytes with a string literal; with byte-buffer JSON this can fail and silently leave tool_choice unset because errors are ignored. Use byte raw payloads so explicit tool-choice behavior is reliably applied. [possible bug]
Severity Level: Critical 🚨
- ❌ Tool-choice translation code blocks package compilation.
- ❌ Explicit tool-choice behavior cannot be exercised in tests.
- ⚠️ OpenAI tool_choice cannot reach Claude requests.Steps of Reproduction ✅
1. From `/workspace/cliproxyapi-plusplus`, run `go test
./pkg/llmproxy/translator/claude/openai/chat-completions` to compile the chat-completions
translator.
2. The compiler reaches the tool-choice mapping logic in
`pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request.go:290-310`,
which maps OpenAI `tool_choice` to Claude `tool_choice`.
3. For the `"auto"` case on line 299, it finds `out, _ = sjson.SetRawBytes(out,
"tool_choice", {"type":"auto"})` (a Go raw string literal), and similarly for `"required"`
on line 301 and the structured JSON case on line 309, all passing `string` values into
`sjson.SetRawBytes`.
4. Since `sjson.SetRawBytes` from `github.com/tidwall/sjson` is used everywhere else with
`[]byte` (e.g., `sjson.SetRawBytes(body, "tools", []byte(placeholder))` in
`pkg/llmproxy/executor/iflow_executor.go:633`), these `string` arguments trigger a
compile-time type error and prevent the package (and tests like
`claude_openai_request_test.go:9-24`) from building; as a result, the suggested runtime
risk of silently missing `tool_choice` settings cannot manifest while the code is in this
state.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/claude/openai/chat-completions/claude_openai_request.go
**Line:** 299:299
**Comment:**
*Possible Bug: Raw tool-choice JSON is set through `SetRawBytes` with a string literal; with byte-buffer JSON this can fail and silently leave `tool_choice` unset because errors are ignored. Use byte raw payloads so explicit tool-choice behavior is reliably applied.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| responseData := contentResult.Get("content").Raw | ||
| part := `{"functionResponse":{"name":"","response":{"result":""}}}` | ||
| part, _ = sjson.SetBytesM(part, "functionResponse.name", funcName) | ||
| part, _ = sjson.SetBytesM(part, "functionResponse.response.result", responseData) | ||
| part, _ = sjson.SetBytes(part, "functionResponse.name", funcName) | ||
| part, _ = sjson.SetBytes(part, "functionResponse.response.result", responseData) |
There was a problem hiding this comment.
Suggestion: contentResult.Get("content").Raw returns JSON text, and writing it with SetBytes stores that JSON as an escaped string rather than structured JSON. Tool result payloads that are objects/arrays will be double-encoded and downstream consumers will receive the wrong shape. Use a raw-set path for valid JSON payloads and only string-set for plain text. [logic error]
Severity Level: Critical 🚨
- ❌ Claude-to-Gemini CLI tool_result requests misrepresent result payloads.
- ❌ Gemini CLI backend tools receive JSON results as plain strings.
- ⚠️ Cross-provider tool integrations via CLI proxy lose structured outputs.Steps of Reproduction ✅
1. In a test similar to `TestConvertClaudeRequestToCLI` in
`pkg/llmproxy/translator/gemini-cli/claude/gemini-cli_claude_request_test.go:9-28`,
construct a Claude-style request JSON where `messages[0].content[0]` is a `tool_result`
with structured JSON content, e.g.:
`{"role":"user","content":[{"type":"tool_result","tool_use_id":"toolu_01","content":{"answer":42}}]}`.
2. Call `ConvertClaudeRequestToCLI("gemini-1.5-pro", input, false)` defined in
`pkg/llmproxy/translator/gemini-cli/claude/gemini-cli_claude_request.go:37`. The function
iterates `messages` and enters the `"tool_result"` branch at lines 110-124.
3. In that branch, `responseData := contentResult.Get("content").Raw` at line 120 yields
the string `{"answer":42}` (raw JSON text). The next line builds `part :=
{"functionResponse":{"name":"","response":{"result":""}}}` at line 121, and then
`sjson.SetBytes` at lines 122-123 encodes `responseData` as a JSON value. Because
`sjson.SetBytes` JSON-encodes its third argument, `result` becomes
`"\"{\\\"answer\\\":42}\""` (JSON string containing the JSON), so the outgoing Gemini CLI
request contains
`"functionResponse":{"name":"toolu_01","response":{"result":"{\"answer\":42}"}}`.
4. When a client uses the Gemini CLI executor
(`pkg/llmproxy/executor/gemini_cli_executor.go:26-56,81-121`) with `opts.SourceFormat` set
to Claude, this converted body is POSTed to the Gemini CLI endpoint. Downstream consumers
that rely on `functionResponse.response.result` being structured JSON (as modeled by
`FunctionResponse.Response map[string]interface{}` in
`pkg/llmproxy/interfaces/client_models.go:41-51`) instead see a stringified blob, so tool
results that are objects/arrays lose their structure and must be reparsed or fail schema
expectations.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** pkg/llmproxy/translator/gemini-cli/claude/gemini-cli_claude_request.go
**Line:** 120:123
**Comment:**
*Logic Error: `contentResult.Get("content").Raw` returns JSON text, and writing it with `SetBytes` stores that JSON as an escaped string rather than structured JSON. Tool result payloads that are objects/arrays will be double-encoded and downstream consumers will receive the wrong shape. Use a raw-set path for valid JSON payloads and only string-set for plain text.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
CodeAnt AI finished running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Daily review limit (50 PRs/day) reached for this repository. Please try again tomorrow. |
1 participant
User description
Summary
Round 2 build repair following PR #956. Reduces failing packages from 15 (with deep cascades) to 11 (with shallower errors), and brings several previously-broken packages fully green.
Now compiling clean:
pkg/llmproxy/auth/kiro/runtime_helpers.gorestored (buildURL, GetAccountKey, setRuntimeHeaders, ParseProfileARN, FetchProfileArn wrapper, sync.Once-backed GetGlobalFingerprintManager) — lifted from prior commit 56f07552 + adapted.pkg/llmproxy/configgainsRemoteManagement.DisableAutoUpdatePanelfield used by managementasset/updater.go.pkg/llmproxy/storemigrated to go-git/v6 alpha API: removedAuth: AuthMethod(no longer exists) →ClientOptions: []client.Option{client.WithHTTPAuth(&githttp.BasicAuth{...})}for Clone/Pull/Push.pkg/llmproxy/thinking/provider/codex/apply.go— drop unused"strings"import.pkg/llmproxy/translator/claude/gemini— add missingregistryimport.pkg/llmproxy/watcher/diff/diff_generated.goshim addsBuildConfigChangeDetailsGeneratedProviders(lifted frompkg/llmproxy/auth/diff/diff_generated.gocodegen output) to satisfy config_diff.go.sjson API repair across translator/*:
sjson.SetBytesMrewritten tosjson.SetBytes.string, the buffer (template/out/completed/item/msg/sysMsg/textPart/etc.) is now[]byteso SetBytes/SetRawBytes type-check; SetRaw on those buffers is rewritten to SetRawBytes.gjson.Parse(byteBuf)→gjson.ParseBytes(byteBuf)where the input changed type.emitRespEventpayload param widened fromstringto[]byte.Remaining failures (round 3)
Tracked separately, all in 11 packages:
FingerprintConfigtype missing,config.Config.KiroFingerprintfield missing,FetchUserEmailWithFallbacksignature changed (3-arg → 5-arg),GlobalFingerprintManagerundefined,codewhisperer_client.gohas unused uuid import.Test plan
go build ./...— 11 packages still failing (down from 15, smaller error sets per package).go test ./...deferred to round 3 once all packages compile.🤖 Generated with Claude Code
Note
Medium Risk
Touches a broad set of request/response translators and git-backed token storage; while changes are mostly mechanical API migrations, they affect JSON shaping and remote sync behavior and could cause subtle runtime regressions.
Overview
Build-fix sweep across
llmproxyto address upstream library API changes.Restores missing Kiro runtime helpers (endpoint/ARN parsing, per-account cache keying, fingerprint-managed runtime headers, and an exported
FetchProfileArnwrapper) and addsRemoteManagement.DisableAutoUpdatePanelto control the management UI auto-updater.Migrates
GitTokenStoreto go-git v6’s new auth plumbing by switching Clone/Pull/Push fromAuthtoClientOptions(HTTP basic auth viaclient.WithHTTPAuth).Updates many translators to the current
sjsonAPI by replacingSetBytesMwithSetBytes, converting intermediate JSON buffers fromstringto[]byte, and adjusting relatedSetRawBytes/ParseBytescall sites; also removes an unused import and adds a missingregistryimport to fix compilation.Reviewed by Cursor Bugbot for commit 0a9b3f6. Bugbot is set up for automated code reviews on this repo. Configure here.
CodeAnt-AI Description
Fix remaining build failures and add a control-panel auto-update toggle
What Changed
Impact
✅ Fewer build failures✅ Management panel updates can be paused✅ Git-backed token storage keeps syncing🔄 Retrigger CodeAnt AI Review
Details
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.