---
id: ERR-2
family: RT-ERR
level: extended
profiles: [runtime]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/rt-err/err-2
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# ERR-2 — Retryability is marked by presence, not by a boolean

*RT-ERR (Part II) · level: extended · profiles: runtime · added in 1.0*

The absence of the marker is load-bearing: the retry gate tests for the literal value true, so anything else (including an explicit false) means do not retry.

## The rule

> **Normative.** This is the rule.
>
> 1. An error output that came from a retryable failure carries `error_retryable` set to `true`.
>
> 2. An error output from a non-retryable failure omits the key entirely rather than setting it to `false`.
>
> 3. Retry applies only where the value is literally `true`.


## What it means

Retryability is not a boolean field with a default; it is a key that either
exists or does not. A retry gate that treats it like an ordinary flag —
`false` as an authoritative "no", any truthy value as a "yes" — reads this
backwards. The gate here checks the value against the literal `true` and
nothing else, so writing `false` on purpose changes nothing: the failure
still does not retry, exactly as an absent key does not.

## Example

The same node failing twice, once in a way the runtime marks retryable and
once in a way it does not.

```json title="A failure the runtime marks retryable" verdict="true"
{"error_retryable": true}
```

```json title="The same shape of failure, unmarked" verdict="absent"
{}
```

## Related rules

- Names: ERR-11
- Referenced by: ERR-6, ERR-11

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.