Debugging EvalView — How to Debug Failing AI Agent Tests
This guide helps you troubleshoot issues when running EvalView tests, including "No response" errors, database issues, timeouts, and tool name mismatches.
HTML Trace Replay — Start Here
The fastest way to debug a failing test is the Trace Replay tab in the HTML report. It shows every LLM call and tool invocation in execution order with full detail.
evalview run --output-format html # Generates report, auto-opens in browser
In the report, click any test card → open the Trace Replay tab. Each span is clickable:
| Span | Expandable detail |
|---|---|
| LLM (blue) | Exact prompt sent to the model, full completion, token counts, finish reason |
| TOOL (amber) | Parameters passed to the tool (JSON), full result returned |
| AGENT (purple) | Root execution boundary, total duration |
Forbidden tool violations appear as a red alert banner above the tabs — the exact tool name that violated the contract is shown, so there is no ambiguity.
This replaces the "add a print statement and re-run" loop. You see what the model saw at step 3 without changing any code.
Note: The Trace Replay tab is richest when your adapter populates
ExecutionTrace.trace_contextviaevalview.core.tracing.Tracer. If it shows "No span data captured", the fallback step list fromtrace.stepsis used instead — it still shows tool calls with parameters and results, but not LLM prompt/completion.
Common Issues
1. Tests Failing with "No response"
Symptom: Test results show final_output: "No response" and score 0
Cause: The adapter isn't parsing the API response correctly
Solution: Run with verbose mode to see what the API is actually returning:
# Option 1: Use --verbose flag
evalview run --verbose
# Option 2: Set DEBUG environment variable
DEBUG=1 evalview run
This will show you:
- 🚀 Request being sent
- 📤 Request payload
- ✅ Response status
- 📥 Each line of the streaming response
- 🔍 Parsed event types
- ⚠️ Unhandled events or errors
2. Database Foreign Key Errors
Symptom: Error message about Foreign key constraint violated for userId
Cause: The test user ID doesn't exist in your database
Solutions:
Option A: Create a test user in your database
-- For PostgreSQL (adjust for your database)
INSERT INTO users (id, email, name)
VALUES ('test-user', 'test@example.com', 'Test User');
Option B: Use a real user ID from your database Edit your test cases to use a valid user:
# tests/test-cases/example.yaml
input:
query: "Your query here"
context:
userId: "your-real-user-id" # Use an actual user ID
Option C: Update your API to handle non-existent test users gracefully
3. Tests Timing Out
Symptom: Tests exceed latency threshold (e.g., 76s instead of 10s)
Possible causes:
- API endpoint is slow
- Database queries are slow
- External API calls are timing out
Solutions:
- Increase timeout in config:
# .evalview/config.yaml
timeout: 120.0 # Increase from 60.0
- Increase latency threshold in test case:
# tests/test-cases/example.yaml
thresholds:
max_latency: 120000 # 120 seconds instead of 10
- Optimize your API endpoints
4. Wrong Tool Names
Symptom: Test shows "missing tools" even though your API is working
Cause: Your API uses different tool names than expected in the test
Solution: Update your test case to match your actual tool names. Run with --verbose to see what tools are actually being called.
Understanding the Adapter
TapeScopeAdapter Event Types
The adapter recognizes these event types from JSONL streaming:
| Event Type | Description | Action |
|---|---|---|
tool_call |
Tool is being executed | Creates a new step |
tool_result |
Tool execution completed | Updates last step with result |
final_message |
Final response from agent | Sets final_output |
token |
Streaming token (SSE) | Appends to final_output |
error |
Error occurred | Sets error message |
start, status, thinking, step_start, step_complete |
Informational | Logged only |
Adding Support for Your Event Format
If your API uses different event types, you can:
Check logs: Run with
--verboseto see what event types your API sendsExtend the adapter: Edit
evalview/adapters/tapescope_adapter.pyto handle your event typesUse HTTPAdapter: If your API returns a simple JSON response (non-streaming), use the HTTPAdapter instead:
# .evalview/config.yaml
adapter: http # Instead of tapescope
endpoint: http://localhost:3000/api/your-endpoint
Verbose Output Example
🔍 Verbose mode enabled
Running test cases...
2025-11-19 22:30:00 - tapescope_adapter - INFO - 🚀 Executing request: Analyze AAPL stock performance...
2025-11-19 22:30:00 - tapescope_adapter - DEBUG - 📤 Payload: {
"message": "Analyze AAPL stock performance",
"route": "orchestrator",
"userId": "test-user"
}
2025-11-19 22:30:00 - tapescope_adapter - INFO - ✅ Response status: 200
2025-11-19 22:30:01 - tapescope_adapter - DEBUG - 📥 Line 1: {"type":"start","data":{"planId":"plan_123"}}
2025-11-19 22:30:01 - tapescope_adapter - DEBUG - 🔍 Event type: 'start'
2025-11-19 22:30:01 - tapescope_adapter - DEBUG - ℹ️ Info event: start
...
Getting Help
If you're still having issues:
- Check the results JSON file:
.evalview/results/TIMESTAMP.json - Look at the
tracesection to see what was captured - Compare
expectedvsactualin the evaluations - Open an issue with the verbose output and your test case
Tips
- Start with simple test cases and gradually add complexity
- Use the conversational route for faster iteration during development
- Check that your API endpoint is actually running before running tests
- Verify your OPENAI_API_KEY is set correctly for LLM-as-judge evaluation
Related Documentation
- Troubleshooting — Common issues with type errors, tool mismatches, and LLM judges
- Adapters — Adapter configuration and response parsing
- Trace Specification — Understanding the execution trace format
- YAML Schema — Test case schema reference
- CLI Reference — Verbose mode and debug flags