# isRetryableReactorError

> **isRetryableReactorError**(`error`): `boolean`

Defined in: [errors/index.ts:296](https://github.com/B3Pay/ic-reactor/blob/2de45f357e6c8bcfa7cb2aa71eff7a059eacdf01/packages/core/src/errors/index.ts#L296)

Whether retrying a failed canister call could plausibly produce a different
result.

The rule is "retry only what the agent reports as a condition that could
differ next time". Concretely:

- [CanisterError](../classes/CanisterError.md) — the canister returned an `Err` variant. Never.
- [ValidationError](../classes/ValidationError.md) — refused by a validator client-side. Never.
- [CallError](../classes/CallError.md) — `Reactor.callMethod` wraps *everything* else in one of
  these, including our own Candid encode/decode and transform failures, so
  the wrapper alone says nothing. The decision comes from the cause:
  - an agent error (it carries a `kind`): retried, except for a rejection
    whose reject code is one the replica will simply repeat;
  - anything else: not retried, because no agent error means no request was
    ever made — the failure happened in encoding, decoding or transforming,
    and the identical input produces the identical failure.
- any other error: not retried, for the same reason.

Within agent errors the bias is toward retrying: an unrecognised `kind`, or a
rejection whose code cannot be read, still retries, so an unfamiliar
transport-level fault is never silently made fatal.

## Parameters

### error

`unknown`

## Returns

`boolean`

## Example

**Opt in on a QueryClient you construct yourself**

```ts
new QueryClient({
  defaultOptions: { queries: { retry: reactorRetry } },
})
```