## TL;DR

The handler verified signatures but applied events in arrival order, so a delayed or replayed old event overwrote newer state. Track per-resource versions or timestamps and ignore events older than the current state.

## Error

```text
a resource flipped back to an old status hours after it had moved on
```

## Steps

1. Add a version or updated_at check per resource Expected: stale events are detectable.
2. Ignore events older than the stored state Expected: replays cannot regress state.
3. Replay the affected resources from a fresh fetch to repair Expected: state is correct again.
4. Keep signature verification as is Expected: security posture unchanged.

## When to use

- State regresses after webhooks
- The handler applies events without ordering

## When not to use

- Events are duplicated, not reordered (then idempotency keys suffice)
- The provider guarantees ordering (rare)

## Tool compatibility

- Webhook event ordering
- Event-driven handlers

## Variant phrasings

### webhook overwrote newer state

Verify signatures AND check event ordering. Ignore stale events.

### stale event replay

Same: track per-resource versions and drop old events.

## Why it happens

Signature verification feels like the whole job, so agents stop there. But networks reorder and providers retry, and old events look exactly like new ones.

## Edge cases

- Use the provider's event id for dedupe plus the resource version for ordering
- Clock skew can make timestamp comparison flaky; prefer monotonic versions

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iSY1UI_otkx2Vzm2Ke5pOA