> ## Documentation Index
> Fetch the complete documentation index at: https://docs.godizzy.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Tool Failures
> Simulate partial results and upstream errors to test how your agent handles incomplete or failed tool responses.
Your agent will eventually call a tool that returns bad data — truncated results, missing fields, or a hard 500. By the time you notice in production, the damage is done. With GoDizzy, you can reproduce these failures deterministically before they happen, without touching your agent code.
This page covers two common failure modes:
* **Partial results** — the tool responds with 200 but returns fewer results than expected
* **Upstream errors** — the tool responds with 500 and an error body
## Partial results (200 with incomplete data)
A search API returns 200 but only includes 2 results instead of the expected 10, and the `nextPage` token is missing. Does your agent retry? Does it fall back? Does it silently produce a worse answer?
In the GoDizzy dashboard, open your route collection and create a new routing rule.
Set the match to:
* **Method:** `GET`
* **Path:** `/search`
Set a priority high enough to match before any other rules on this path.
Choose **Mock** as the action. This tells GoDizzy to return your configured fixture instead of forwarding the request to the real search API.
Set **Status** to `200`. Paste the following into the **Body** field:
```json mock body theme={null}
{
"results": [
{
"id": "result_001",
"title": "Getting started with vector databases",
"url": "https://example.com/docs/vector-db",
"score": 0.94
},
{
"id": "result_002",
"title": "Embeddings and semantic search",
"url": "https://example.com/blog/embeddings",
"score": 0.87
}
],
"total": 2
}
```
Notice what is missing: `nextPage` is absent, and `total` is 2 even though the agent may expect 10 or more results. This is a valid 200 — the API did not fail — but the data is incomplete.
Leave **Latency** at its defaults unless you also want to simulate a slow partial response.
Save the rule. Your agent already points at your collection's GoDizzy URL (e.g. `https://your-collection.godizzy.dev`). No code changes needed — requests to `GET /search` now return the partial fixture.
### What the agent sees
```http theme={null}
GET /search?q=vector+databases HTTP/1.1
Host: your-collection.godizzy.dev
```
```http theme={null}
HTTP/1.1 200 OK
Content-Type: application/json
{
"results": [
{
"id": "result_001",
"title": "Getting started with vector databases",
"url": "https://example.com/docs/vector-db",
"score": 0.94
},
{
"id": "result_002",
"title": "Embeddings and semantic search",
"url": "https://example.com/blog/embeddings",
"score": 0.87
}
],
"total": 2
}
```
### What to test
* Does your agent accept 2 results and continue, or does it retry the search?
* Does your agent check `nextPage` before deciding the result set is complete?
* Does the agent's final output degrade in a noticeable or unacceptable way?
* If the agent retries, does it back off or loop indefinitely?
To test retry logic specifically, create a second rule at lower priority that proxies to the real search API. Run the mock first to confirm retry behavior, then drop the mock rule's priority below the proxy rule to let real traffic through — no agent code changes required.
***
## Upstream errors (500 with an error body)
Now simulate the search API going down entirely. Your agent calls the tool and gets a 500. Does it surface the error? Does it try a fallback tool? Does it halt?
Create a new rule (or edit the existing one) with the same match:
* **Method:** `GET`
* **Path:** `/search`
Choose **Mock** as the action.
Set **Status** to `500`. Paste the following into the **Body** field:
```json mock body theme={null}
{
"error": {
"code": "INTERNAL_ERROR",
"message": "An unexpected error occurred while processing your request.",
"request_id": "req_8f2a91bc"
}
}
```
Optionally, set a **Latency** range (e.g. min 200ms, max 800ms) to simulate the delay before a server failure response.
Save the rule. Your agent now receives a 500 on every search call.
### What the agent sees
```http theme={null}
GET /search?q=vector+databases HTTP/1.1
Host: your-collection.godizzy.dev
```
```http theme={null}
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{
"error": {
"code": "INTERNAL_ERROR",
"message": "An unexpected error occurred while processing your request.",
"request_id": "req_8f2a91bc"
}
}
```
### What to test
* Does your agent catch the 500 and surface a meaningful message to the user?
* Does it attempt a fallback (e.g. a different tool or a cached result)?
* Does it retry on 500, and if so, how many times before giving up?
* Does the agent halt or continue with degraded output?
A silent failure — where the agent continues as if nothing happened — is often harder to detect than a crash. Watch for cases where the agent produces an answer without acknowledging it could not retrieve search results.
***
## Switch back to the real API
When you are done testing, flip the rule from **Mock** to **Proxy** in the dashboard. Your agent immediately starts hitting the real search API. Same URL, no code changes.