Skip to main content
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?
1

Create a routing rule for the tool endpoint

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.
2

Set the action to mock

Choose Mock as the action. This tells GoDizzy to return your configured fixture instead of forwarding the request to the real search API.
3

Configure the mock response body

Set Status to 200. Paste the following into the Body field:
mock body
{
  "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.
4

Save and point your agent at the GoDizzy URL

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

GET /search?q=vector+databases HTTP/1.1
Host: your-collection.godizzy.dev

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?
1

Create a routing rule for the tool endpoint

Create a new rule (or edit the existing one) with the same match:
  • Method: GET
  • Path: /search
2

Set the action to mock

Choose Mock as the action.
3

Configure the mock response body with a 500 status

Set Status to 500. Paste the following into the Body field:
mock body
{
  "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.
4

Save and run your agent

Save the rule. Your agent now receives a 500 on every search call.

​
What the agent sees

GET /search?q=vector+databases HTTP/1.1
Host: your-collection.godizzy.dev

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.