fix(gateway): guard against non-iterable messages in tool-calling.ts#2325
fix(gateway): guard against non-iterable messages in tool-calling.ts#2325kilo-code-bot[bot] wants to merge 3 commits intomainfrom
Conversation
Clients can send requests without a messages array, causing TypeError: e.messages is not iterable at runtime. The route handler parses bodies with JSON.parse + type assertions only, so messages is never validated. Add Array.isArray guard in the route handler (returns 400) and defense-in-depth guards in all downstream functions that iterate over messages.
| // Validate that messages is a non-empty array for request kinds that require it | ||
| if ( | ||
| (requestBodyParsed.kind === 'chat_completions' || requestBodyParsed.kind === 'messages') && | ||
| !Array.isArray(requestBodyParsed.body.messages) |
There was a problem hiding this comment.
WARNING: Array-only validation still allows malformed message entries
This guard only checks that messages is an array. Requests like {"messages":[null]} or {"messages":[{"role":"user"}]} still pass here and can still throw later when downstream code reads m.role or calls content.filter(...) in the prompt-extraction helpers. Because this route is still parsing raw JSON without schema validation, it needs to reject non-object / non-conforming message items as well to fully prevent the runtime 500s this PR is targeting.
There was a problem hiding this comment.
This is a valid concern for a follow-up, but out of scope for this PR. The Sentry error is specifically TypeError: e.messages is not iterable — meaning messages is undefined/null/non-array, not that individual items within the array are malformed. Adding full Zod schema validation for the entire request body would be a larger effort that should be done separately. The Array.isArray guard matches the existing pattern used by repairTools in the same file and the addCacheBreakpoints function in request-helpers.ts.
Code Review SummaryStatus: 1 Issues Found | Recommendation: Address before merge Overview
Fix these issues in Kilo Cloud Issue Details (click to expand)WARNING
Other Observations (not in diff)No additional issues found outside the diff. The previously reported route-level validation gap remains unresolved in unchanged code. Files Reviewed (1 files)
Reviewed by gpt-5.4-20260305 · 371,452 tokens |
…cktrace The Sentry issue points specifically to tool-calling.ts in the POST /api/gateway/[...path] handler. Reverted defensive guards in unrelated files.
The isEligibleForFirstMonthPromo tests hardcoded 'true' but the promo cutoff (2026-04-11T06:59:59Z) has passed, causing CI to fail. Use the cutoff constant to compute the expected value dynamically.
Summary
Fixes Sentry error
TypeError: e.messages is not iterablein kilocode-web, occurring inapps/web/src/lib/tool-calling.tsduringPOST /api/gateway/[...path].The API gateway route handler parses incoming request bodies with
JSON.parseand TypeScript type assertions only — there is no runtime validation that themessagesfield exists and is an array. When a client sends a chat completions request without amessagesarray,normalizeToolCallIdscrashes when iterating over it withfor...of.Two changes:
route.ts): Validatesmessagesis an array forchat_completionsandmessagesrequest kinds, returning 400 early if not. This matches the existing validation pattern for themodelfield.normalizeToolCallIds(tool-calling.ts): AddedArray.isArrayguard beforefor...ofiteration, matching the existing pattern used byrepairToolsin the same file.Verification
tool-calling.tsinPOST /api/gateway/[...path]Array.isArrayguard matches the existing pattern inrepairTools(same file, line 82-84)modelfield validationVisual Changes
N/A
Reviewer Notes
repairTools(same file) already hasif (!Array.isArray(requestToMutate.messages)) { return; }— the same guard is now applied tonormalizeToolCallIds.Built for Christiaan Arnoldus by Kilo for Slack