···216216A fetch that errors while carrying conditions is also treated as a skip;
217217see [Interaction with fetch errors](#interaction-with-fetch-errors).
218218219219+## Retries on transient failures
220220+221221+Every outbound request made by the fetchers (PDS `getRecord`, `listRecords`,
222222+appview `getRelationships`) goes through `fetchWithRetry` in
223223+[lib/pds/fetch-with-retry.ts](../lib/pds/fetch-with-retry.ts). A single request
224224+is transparently retried on:
225225+226226+- Thrown errors from `fetch` (DNS failure, connection reset, TLS error).
227227+- `AbortSignal.timeout` firing (per-attempt timeout).
228228+- Any `5xx` response from the server.
229229+230230+Retry schedule: `1s + 3s` (two retries). 4xx responses are stable answers and
231231+are never retried; in particular, 404 and the XRPC `RecordNotFound` body on
232232+HTTP 400 still resolve to `found: false` on the first attempt.
233233+234234+Retries run inline in the handler, so a slow retry does delay the event's
235235+processing. Two retries with this schedule add at most ~4s on top of the
236236+per-attempt timeouts (currently 10s each). After retries are exhausted, the
237237+error surfaces to the caller as described below.
238238+219239## Interaction with fetch errors
220240221221-A fetch **error** (bad URI, PDS unreachable, search throws) is distinct from a
222222-fetch **not-finding** anything. Errors are collected into the `errors` array
223223-on the `FetchResolution` and the entry is not added to the context.
241241+A fetch **error** (bad URI, PDS unreachable after retries, search throws) is
242242+distinct from a fetch **not-finding** anything. Errors are collected into the
243243+`errors` array on the `FetchResolution` and the entry is not added to the
244244+context.
224245225246Whether the automation fires when a fetch errors depends on whether that
226247fetch carries **conditions**: