mirror of
https://github.com/getmaxun/maxun.git
synced 2026-10-17 04:30:39 +08:00
hmhngx
c8db638344
All 3 verified against current code and the actual failure modes before
fixing, not applied blindly from the bot's suggestion text.
1. getLLMDecisionWithVision: the Anthropic image block declared
media_type: 'image/png' while the screenshot is captured as JPEG
(page.screenshot({ type: 'jpeg' })). This is the exact mismatch already
disclosed (by me) in the PR's "Note to Reviewers" before CodeRabbit
caught it independently, confirmed against Anthropic's own docs that a
media_type mismatch can 400 before the forced tool call ever runs.
Fixed to 'image/jpeg'. The identical bug also exists in the untouched
openai branch's `data:image/png;base64,...` URL - left as-is and
flagged, not silently fixed, since that branch is explicitly out of
this PR's scope.
2. parseSearchIntent: the validation `!intent.searchQuery ||
!intent.extractionGoal` is a truthiness check, not a type check. Since
callAnthropicWithTool returns raw tool_use.input with no strict-mode
validation, a non-string value (e.g. an object) passes this guard, and
downstream `encodeURIComponent(query)` (workflowEnricher.ts, both
performDuckDuckGoSearch and performDuckDuckGoMultiSearch) silently
turns it into the literal string "[object Object]" as a search query.
Verified this exact call chain before fixing. Replaced with a guard
that requires searchQuery/extractionGoal to be non-blank strings and
limit (when present) to be an integer. Applied to both the anthropic
branch's copy of this check AND the shared ollama/openai JSON-parsing
branch's identical copy, per CodeRabbit's own comment text ("Apply the
same validation to the JSON parsing branch") - not my own scope
expansion, the finding explicitly asked for both.
3. selectMultipleUrlsFromResults: the per-index collection loop had no
cap on `result.length`, so a tool response returning more valid,
unique-domain indices than the caller's `maxSites`/`cap` would collect
all of them instead of stopping at cap - e.g. 5 valid indices with
cap=4 would produce 5 downstream workflows instead of 4. Added
`if (result.length >= cap) break;` at the top of the loop, matching
CodeRabbit's exact suggested diff. This identical bug also exists,
unchanged, in the original shared-tail copy of this same loop (which
predates this PR and serves ollama/openai) - CodeRabbit's finding did
not ask for that copy to be fixed too, so it's flagged, not touched.
Verified: full project tsc --noEmit clean. A targeted test reproduced each
finding's exact described failure mode against the pre-fix code path
conceptually and confirmed the fix resolves it: searchQuery as an object,
as an array, as an empty/whitespace string, limit as a fraction, and limit
as a numeric string are all now correctly rejected (falling back to the
existing regex heuristic, not silently proceeding); valid inputs including
an omitted limit still succeed unchanged; 5 valid unique-domain indices
against cap=4 now correctly returns exactly 4, and a below-cap selection
is unaffected. Re-ran the full 9-site fallback regression afterward to
confirm the shared-code changes (finding #2) didn't affect any of the
other 8 sites.