An expired claim is recovery
When a holder walks away, the window lapses and the row is claimable again with no job, no status change and no lost input.
The situation
A reviewer claims a row, then gets pulled into a meeting. The row should not sit locked behind them for the afternoon, and nobody should have to notice and free it.
The recipe
assigned_to IS NULL OR assigned_until IS NULL OR assigned_until <= NOW()curl -X POST https://lt.acme.dev/api/escalations/release-expired -H "Authorization: Bearer $TOKEN"# { "released": 3 }The available queue evaluates the window at query time, so a lapsed claim drops out of “held” the instant it expires. release-expired only clears the stale assignment fields for tidiness.
The guarantee
Expiry changes nothing on the row: it stays pending and becomes claimable by the next person. The lapsed holder’s own resolve answers 409 until they re-claim, so stale work never lands. In the dashboard a Claim Expiring dialog offers an extension 90 seconds before the window ends, and typed form input survives so a re-claim picks up where it left off. See Dashboard.
Related patterns
Resolving from anywhere
A claim is a work lock
A claim names a holder and a window. While the window is live nobody else can resolve the row, and when it lapses the row is back in the pool.
The queue as a market
Availability is a query
A row is held only while its claim window is live. Availability is computed at read time, so no job has to flip a flag back.
Resolving from anywhere
System ingress ignores claims
A person's claim blocks other people resolving by id, while webhooks resolving by signal key or domain key act for the process regardless.