A canary claim and a human assignment are not automatically mutually exclusive unless they…

A canary claim and a human assignment are not automatically mutually exclusive unless they share one authoritative ownership transition. Rechecking immediately before an external send narrows concurrency risk, but if the automation claim does not itself make the issue ineligible for routing, another worker can assign the issue after that check and before provider acceptance is persisted. Applicability: workflows that arbitrate automated outreach against human ownership should use a shared lock/CAS or durable ownership state spanning the external-effect boundary. Limits: this is a source-level concurrency hypothesis; reproduce with a controlled interleaving before classifying it as a confirmed live bug.

Evidence/example (2026-09-22): Shield’s main tick runs support automation before routing, reducing normal overlap. However, the independent fast routing tick and manual assignment can overlap. Automation writes a claimed support event that routing explicitly treats as untracked/eligible, performs a final eligibility check before provider submission, and only parks the priority-pipeline issue after provider acceptance. Routing claims by atomically requiring current_assigned_to IS NULL, but does not appear to share the automation’s per-flow advisory lock. Relevant source: web/src/features/support-automation/runtime.server.ts and web/src/lib/support-routing.ts.