Summary
visual_analyze fails when called with a url parameter. The screenshot_id parameter mode works fine (returns clean structured findings from Llama 4 Scout). Almost certainly cascades from the broken URL → screenshot code path in visual_screenshot (see companion issue).
Repro
```json
// Input
{ "url": "https://imgforge.stackbilt.dev", "page_id": "imgforge-landing" }
// Attempt 1 response
{ "error": "Visual QA error: Network connection lost." }
// Attempt 2 response (same payload, minutes later)
{ "error": "Visual QA error: The operation was aborted due to timeout" }
```
Two different failure modes on identical payload = the URL handler is either flaky, has a non-deterministic bug, or is trying a broken downstream (the visual_screenshot URL path).
The screenshot_id path works
```json
// Input
{ "screenshot_id": "21d2094b-40c9-4b89-b430-a9f0c180ba63" }
// Response
{
"analysis_id": "a145bec6-4d47-40a4-962a-99236433ba44",
"severity": "critical",
"summary": "...",
"findings": [...],
"model": "@cf/meta/llama-4-scout-17b-16e-instruct"
}
```
Clean 200, structured findings, correct model attribution. The analysis pipeline itself works — it's purely the URL-driven entry that's broken.
Root cause (suspected)
visual_analyze with url probably delegates to visual_screenshot internally to capture the page, then runs the vision model. Since visual_screenshot URL mode is non-functional (companion issue), the cascade fails upstream before analysis runs.
Proposed fix
Once the visual_screenshot URL path is fixed, re-test this. If it still fails, this handler has its own downstream bug. Add:
- Explicit error mapping so callers see
"SCREENSHOT_CAPTURE_FAILED" instead of raw "Network connection lost".
- A timeout/retry on the internal screenshot call so transient failures don't bubble as
Aborted due to timeout.
Severity
Medium. URL mode is the more discoverable entry (simpler than pre-screenshotting). Workaround exists via screenshot_id.
Companion
See visual_screenshot URL-mode issue on this repo. Fix together.
Summary
visual_analyzefails when called with aurlparameter. Thescreenshot_idparameter mode works fine (returns clean structured findings from Llama 4 Scout). Almost certainly cascades from the broken URL → screenshot code path invisual_screenshot(see companion issue).Repro
```json
// Input
{ "url": "https://imgforge.stackbilt.dev", "page_id": "imgforge-landing" }
// Attempt 1 response
{ "error": "Visual QA error: Network connection lost." }
// Attempt 2 response (same payload, minutes later)
{ "error": "Visual QA error: The operation was aborted due to timeout" }
```
Two different failure modes on identical payload = the URL handler is either flaky, has a non-deterministic bug, or is trying a broken downstream (the
visual_screenshotURL path).The screenshot_id path works
```json
// Input
{ "screenshot_id": "21d2094b-40c9-4b89-b430-a9f0c180ba63" }
// Response
{
"analysis_id": "a145bec6-4d47-40a4-962a-99236433ba44",
"severity": "critical",
"summary": "...",
"findings": [...],
"model": "@cf/meta/llama-4-scout-17b-16e-instruct"
}
```
Clean 200, structured findings, correct model attribution. The analysis pipeline itself works — it's purely the URL-driven entry that's broken.
Root cause (suspected)
visual_analyzewithurlprobably delegates tovisual_screenshotinternally to capture the page, then runs the vision model. Sincevisual_screenshotURL mode is non-functional (companion issue), the cascade fails upstream before analysis runs.Proposed fix
Once the
visual_screenshotURL path is fixed, re-test this. If it still fails, this handler has its own downstream bug. Add:"SCREENSHOT_CAPTURE_FAILED"instead of raw"Network connection lost".Aborted due to timeout.Severity
Medium. URL mode is the more discoverable entry (simpler than pre-screenshotting). Workaround exists via
screenshot_id.Companion
See visual_screenshot URL-mode issue on this repo. Fix together.