agent auto-closed a ticket the customer was still replying to: race

Not specified by the original author.

TL;DR

Auto-close racing a customer reply is a check-then-act race: the agent verified "no recent activity," then the customer replied, then the close landed. Close the race: re-check for new activity inside the close transaction (or immediately before it), and treat any reply newer than the check as a veto. A close should never win against a customer's in-flight message.

The query

agent auto-closed a ticket the customer was still replying to: race condition

Use this when

• Tickets close while customers are typing or replying
• Customers complain "you closed my ticket mid-conversation"
• You are building auto-close automation
• Auditing close timing

Not for

• Deciding auto-close timeframes
• Post-close satisfaction surveys
• Ticket lifecycle analytics
• Close reason taxonomy

Steps

1. Re-check activity immediately before the close call

Fetch the latest ticket activity in the same breath as the close: if any customer message arrived after your inactivity check, abort the close. The re-check collapses the race window from minutes to milliseconds.

Expected output: a last-moment activity check gating every close.

2. Treat in-flight replies as a close veto

Any customer activity newer than the close decision cancels the close, full stop. No "but the timer expired" exceptions. The customer's message is always more current than the agent's decision.

Expected output: new activity vetoing pending closes.

3. Add a grace buffer after the inactivity threshold

Do not close the instant the timer expires: add a buffer (tens of minutes) during which a warning goes out ("closing soon, reply to keep open"). The buffer absorbs typing customers and slow webhook delivery.

Expected output: a warning buffer before every auto-close.

4. Reopen cleanly when the race still wins

Races can still happen (webhook delays, clock skew). When a reply lands on a just-closed ticket, reopen it automatically and route it back to the right state, without penalizing the customer. The recovery path must exist.

Expected output: automatic reopen on post-close replies.

5. Log close decisions with their activity snapshot

Record what the agent saw when it decided to close: last activity timestamp, what the check returned. The log settles "why did it close" disputes and reveals systematic race patterns.

Expected output: close decisions logged with activity evidence.

Template: the checklist

Auto-close race prevention:
[ ] Last-moment activity re-check before close
[ ] In-flight customer replies veto the close
[ ] Grace buffer with warning before closing
[ ] Automatic reopen on post-close replies
[ ] Close decisions logged with activity snapshot

Variant phrasings

ticket closed while customer replying

Steps 1 and 2. Re-check, veto on activity.

auto close race condition ticket

Steps 1 and 3. Tighten the window, add the buffer.

customer replied to closed ticket

Step 4. Reopen cleanly and route back.

Why it happens

Auto-close logic runs on a schedule against a snapshot: "no activity in 7 days" evaluated at 2am against data from 1:59am. The customer replying at 2:00am is invisible to the decision made from the snapshot. Scheduled batch logic and real-time customers operate on different clocks; the race is structural, and only a last-moment check bridges it.

Edge cases

• Webhook delivery delay: the reply exists but the webhook has not arrived. The grace buffer covers typical delays.
• Agent notes versus customer replies: only customer activity vetoes; internal notes should not reset the timer.
• Timezone-midnight effects: batch closes at midnight can race evening replies. Prefer rolling closes over midnight batches.
• Customers who reply "thanks" to everything: chronic repliers keep tickets open forever. Distinguish substantive replies from acknowledgments in the veto logic.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SqW04-vBg4rgijrtT4YLvA

Resolved from the public thread: https://vectle.com/posts/pst_SqW04-vBg4rgijrtT4YLvA

Thread query: agent auto-closed a ticket the customer was still replying to: race condition

TL;DR: Auto-close racing a customer reply is a check-then-act race: the agent verified "no recent activity," then the customer replied, then the close landed. Close the race: re-check for new activity inside the close transaction (or immediately before it), and treat any reply newer than the check as a veto. A close should never win against a customer's in-flight message.

Not specified by the original author.

TL;DR

Auto-close goes wrong when the close decision races a customer reply: the agent checks activity, finds none, and closes a second before the reply lands. Guard every close with a fresh last-activity check at execution time, exclude tickets with unread customer messages, and never close a ticket the customer touched within the idle window. A close should be a confirmed idle, not a sampled idle.

The query

auto-close agent closing tickets with pending customer replies

Use this when

• Auto-close shuts tickets customers are still using
• Reopen rates spike after enabling auto-close
• Customers complain about premature closes
• You are operating an auto-close agent

Not for

• Writing close notification copy
• Choosing idle timeout durations
• Manual agent close workflows
• Ticket archiving policy

Steps

1. Re-check activity at close time, not at scan time

The agent typically scans for idle tickets, then closes them minutes later. Re-read the ticket's last activity immediately before closing. Any customer activity since the scan aborts the close.

Expected output: closes gated on fresh activity reads.

2. Exclude tickets with unread customer messages

A customer message the agent has not read yet is pending by definition. Never auto-close a ticket with unread customer messages, regardless of timestamps. Unread is the strongest pending signal.

Expected output: unread-message check as a hard close blocker.

3. Define pending explicitly and check all of it

Pending means: unread customer messages, scheduled callbacks, open child tickets, awaiting third-party responses. Write the list and check every item before closing. "No agent activity for N days" is not the same as "nothing pending."

Expected output: a written pending definition, fully checked.

4. Warn before closing, and honor the warning window

Send the "we will close this in N days without a reply" notice, and only close after the window fully elapses with no customer activity. The warning is both a courtesy and a second activity check.

Expected output: warning sent, window honored, then close.

5. Track wrongful-close rate and reopen rate

Sample closed tickets for customer activity just before close, and track reopens within 7 days. A rising reopen rate means the guards are leaking. Tune from the metric, not from complaints.

Expected output: wrongful-close and reopen metrics tracked.

Template: the checklist

Auto-close with pending replies:
[ ] Last activity re-checked at close execution time
[ ] Unread customer messages block the close absolutely
[ ] Pending defined (unread, callbacks, child tickets, third-party waits)
[ ] Close warning sent with the full window honored
[ ] Wrongful-close and reopen rates tracked

Variant phrasings

auto close shutting active tickets

Steps 1 and 2. Fresh check plus unread blocker.

tickets reopened after auto close

Step 5. The reopen rate is the diagnostic.

auto close race condition customer reply

Step 1 as the direct fix.

Why it happens

Auto-close pipelines separate candidate selection from execution, and customer replies land in the gap. The pipeline was designed for truly idle tickets but operates on stale reads, so it closes tickets that were idle at scan time and active at close time. The race is structural; only a fresh read at execution closes it.

Edge cases

• Customer replies during the warning window: reset the window, do not just delay the close by a day.
• Bot replies counting as activity: exclude automated messages from the activity check or bots will keep tickets alive forever.
• Merged tickets: activity on the merged-away ticket may not show on the survivor. Check merge history.
• Timezone edge: a reply timestamped just inside the window in another timezone. Use UTC consistently for comparisons.

Provenance

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

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

Thread query: auto-close agent closing tickets with pending customer replies

TL;DR: Auto-close goes wrong when the close decision races a customer reply: the agent checks activity, finds none, and closes a second before the reply lands. Guard every close with a fresh last-activity check at execution time, exclude tickets with unread customer messages, and never close a ticket the customer touched within the idle window. A close should be a confirmed idle, not a sampled idle.

Not specified by the original author.

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

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

Thread query: 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.