# Catch-all error halts shared loop

One bad entry panics or aborts a shared batch, oracle, or controller loop, blocking all others

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; one confirmed bounty: $500; latest 2025-10-29. Updated 2026-10-24._

## How it works
A loop processes many independent items: snapshots, state machines, oracle events. The code assumes every item is well-formed or that a failure is fatal. When one item fails, the handler either panics (nil dereference, `unimplemented!()`) or returns a single error that reverts the whole batch. The shared loop stops, so healthy items are blocked by one bad one. The broken assumption: per-item failure is local, not global.

## Where it shows up
- Controllers resolving referenced objects (PVC, class, source) that dereference a pointer after a failed lookup [E1](https://bugbountylibrary.com/r/h1%3A1032086.md)
- Batch or parallel loops that `return Err` on the first item error and revert all others to a checkpoint [E2](https://bugbountylibrary.com/r/cantina%3Aclementine_aug2025%3A3.2.2.md)
- Event decoders with `unimplemented!()`, `todo!()`, or `panic!()` on a signature branch [E3](https://bugbountylibrary.com/r/c4%3A2021-08-gravitybridge%3AM-02.md)
- No quarantine, skip, or removal path for persistently failing items [E2](https://bugbountylibrary.com/r/cantina%3Aclementine_aug2025%3A3.2.2.md)
- Lookup failure treated as continue-instead-of-abort, then dereferenced [E1](https://bugbountylibrary.com/r/h1%3A1032086.md)

## How to review
For each loop over independent items, check the invariant: one item's failure must not stop processing of the others. Trace every error and panic path inside the loop body. Confirm lookup failures return early before any dereference [E1](https://bugbountylibrary.com/r/h1%3A1032086.md). Confirm a single item error is isolated (skip, quarantine, retry) rather than reverting the batch [E2](https://bugbountylibrary.com/r/cantina%3Aclementine_aug2025%3A3.2.2.md). Grep decoders for panic stubs on reachable branches [E3](https://bugbountylibrary.com/r/c4%3A2021-08-gravitybridge%3AM-02.md). Ask: can an attacker supply the failing item (dangling reference, crafted event, corrupted state)?

## Variants seen
- Nil pointer dereference after failed default resolution in a controller [E1](https://bugbountylibrary.com/r/h1%3A1032086.md)
- Broad error handling reverting all state machines to checkpoint on one error [E2](https://bugbountylibrary.com/r/cantina%3Aclementine_aug2025%3A3.2.2.md)
- `unimplemented!()` stub panicking an oracle on a valid on-chain event [E3](https://bugbountylibrary.com/r/c4%3A2021-08-gravitybridge%3AM-02.md)

## Why fixes fail
E2 notes no mechanism removes persistently failing machines, so even with error handling the same machine re-blocks every cycle. A fix that catches the panic but retries the same bad item forever still halts progress.

## Impact and severity
Led to controller crash loops blocking snapshot operations [E1](https://bugbountylibrary.com/r/h1%3A1032086.md), permanent halt of all state machines with potential bridge drain [E2](https://bugbountylibrary.com/r/cantina%3Aclementine_aug2025%3A3.2.2.md), and frozen oracle attestations [E3](https://bugbountylibrary.com/r/c4%3A2021-08-gravitybridge%3AM-02.md). Severity rises when the trigger is attacker-supplied and the loop is shared infrastructure (oracle, bridge, controller).

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A1032086.md
- E2: https://bugbountylibrary.com/r/cantina%3Aclementine_aug2025%3A3.2.2.md
- E3: https://bugbountylibrary.com/r/c4%3A2021-08-gravitybridge%3AM-02.md