## TL;DR
The agent read the ticket state, the state changed, and the agent closed based on the stale read. Re-read the status immediately before closing and abort when it changed since the read.

## The query
```text
auto-close agent closed an active p1 ticket: stale-status race condition
```

## Use this when
- active P1s get auto-closed
- the close reason cites outdated state
- status changed between agent read and write

## Not for
- agents closing genuinely resolved tickets
- human close mistakes
- SLA-based auto-close policy debates

## Steps
1. Reconstruct the race: find the read timestamp and the status change timestamp. Expected output: the stale window is proven.
2. Add a fresh status read immediately before any close action. Expected output: closes use current state.
3. Abort the close when the status changed since the agent's assessment. Expected output: changed tickets stay open.
4. Use optimistic locking or etags on the update where the API supports it. Expected output: concurrent writes cannot silently win.
5. Require human approval for auto-closing P1 and P2 tickets. Expected output: high-severity closes always have eyes on them.

## Applies to
Auto-close agents, ServiceNow, Jira, any ITSM with concurrent updates.

## Variant phrasings
### Close based on a monitoring clear that flapped
Require the clear to persist for a dwell time before closing.

### Two agents closing the same ticket
Namespace close authority to one agent or serialize through a queue.

## Why it happens
Read-then-write without revalidation is a race condition. On busy P1s, the status always changes under you.

## Edge cases
- Log the status at decision time and at close time; the diff is the audit trail.
- P1s should probably never auto-close; consider removing them from scope.
- Test with simulated concurrent updates in staging.

## Provenance

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