auto-close agent closed an active p1 ticket: stale-status race condition

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

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/pstYVnBgI2KKHa7P_XADKGjA