Troubleshoot Web search when results are missing or blocked
Duale AI Web search troubleshooting covers missing results, blocked pages, absent sources, and task deadline failures.
Troubleshoot Web search failures by starting from the visible symptom and adjusting constraints, sources, or retry behavior based on the specific failure mode.
- The SDK does not expose a stable Web-specific error code; use task problem details instead.
- For unreadable pages, do not bypass CAPTCHA or rate limits; request another accessible source.
- Use Request Web research to keep final URLs, dates, and gaps in the terminal result.
- Before retrying a failed task, check status and external effect to avoid repeating page requests.
Summaries were generated by AI. Generative AI is experimental.
The SDK reports terminal task failures. It does not report a stable Web-specific error code. Do not parse answer text to classify a Web failure. Start with the visible symptom and use SDK problem details only when the whole task fails.
If a task trace is available, it can show that Duale AI selected and dispatched a Web tool. It does not prove that the tool completed, that a page returned useful content, or that the answer used it. Evidence and audit defines what the record proves.
Search returns no useful result
Change only the part of the request that explains the symptom:
- If the answer reports no result, remove one date, language, country, or domain constraint at a time.
- If the sources are old, give an exact cutoff date. Ask for publication and effective dates, then check the primary publisher directly.
- If the sources are irrelevant, name the entity, place, date, and preferred source type more precisely.
- If the result includes no final source URLs, ask for final public URLs and evidence gaps. This request does not guarantee that the agent will use Web search or page access.
Check. The revised result answers the same question, names final URLs, and states any remaining gap. Stop if a broader request would change the question or require sensitive data.
A page cannot be read
Use a different public representation when a page is blocked, unreadable, or unsupported:
- For a CAPTCHA, blocked automation, or a publisher rate limit, do not bypass the control. Ask for another accessible source. Stop repeated submissions to the same publisher.
- For little or no extracted text, provide a direct article or document URL. You can also ask for a smaller public representation or a source from another publisher.
- If page continuity is missing, do not depend on prior site state. Use a public page that needs no sign-in.
Page access states the interactions that the feature does not provide. Report the evidence gap if no permitted source supports the claim.
Check. Open the final URL independently. Confirm that the visible page contains the material the result assigns to it. If the source still needs a sign-in, challenge bypass, private-network route, or unsupported interaction, stop.
The answer has no usable sources
For a new task, use Request Web research to keep final URLs, dates, disagreements, and gaps in the terminal result.
Check. Open each material source and locate the supporting text. If you cannot find it, keep the claim unsupported.
The task fails or reaches its deadline
If await response.model() raises an SDK task error, follow Errors and reliability. Branch on
the task’s problem details, not on a Web error that the SDK does not expose. Retry only when the task error permits it.
Before you submit the whole task again, check its status and any external effect. A retry can repeat page requests and calls to your registered tools. Page access covers page requests, and Secure integration covers repeat-safe tools and approval.
Check. A recovered task reaches a terminal result and does not repeat an external action. If the same task failure returns, stop and keep the task ID and problem details with your incident record.
After recovery, apply the acceptance test in Sources and factuality before you use a material claim.