# Common Error Cases

Use this reference to expand beyond the happy path. Favor error cases that a real user or operator is likely to hit.

## Configuration Errors

Check whether the runtime behaves differently for:

- Missing required environment variables.
- Present but malformed secrets or identifiers.
- Wrong endpoint or base URL.
- Wrong model or deployment name.
- Incompatible local dependency versions.

Look for:

- Error type and status code.
- Whether the failure is immediate or delayed.
- Whether the message is actionable.
- Whether retrying without fixing configuration changes anything.

## Input Errors

Probe common bad-input patterns such as:

- Missing required fields.
- Wrong data type.
- Unsupported enum or option value.
- Empty but syntactically valid input.
- Oversized input or too many items.
- Mutually incompatible options.

Prefer realistic invalid inputs over artificial nonsense. The point is to learn how the runtime fails in practice.

## Transport and Availability Errors

When networked services are involved, consider:

- Connection failure.
- Read timeout.
- Server timeout or upstream gateway error.
- Rate limit response.
- Partial stream interruption.
- Reusing a connection after a failure.

Capture whether the client library retries automatically, whether it surfaces retry metadata, and whether the final exception preserves the original cause.

## State and Repetition Errors

Many surprising bugs appear only when an operation is repeated or interrupted:

- Re-submit the same request.
- Repeat after a timeout.
- Retry after a partial tool call or partial stream.
- Resume after local cleanup or process restart.
- Repeat with slightly changed inputs while reusing shared state.

Observe whether the operation is idempotent, duplicated, silently ignored, or left in a partial state.

## Concurrency Errors

When shared state, ordering, or isolation may matter, consider:

- Two overlapping requests with the same logical input.
- Parallel runs that reuse the same cache key, session, container, or temporary resource.
- Concurrent retries, cancellation, or cleanup racing with active work.
- Output or event streams from one run leaking into another.

Capture whether the runtime serializes, rejects, duplicates, corrupts, or cross-contaminates the work.

## Investigation Heuristics

Use these heuristics to pick error cases quickly:

- Ask which failure a real engineer would debug first in production.
- Ask which failure is most expensive if it is misunderstood.
- Ask which failure would be invisible from code review alone.
- Ask which failure path is likely to differ across environments.

If the error behavior is already perfectly obvious from a local validator or type system, it is usually low priority for this skill.