A walk-in registers while the doctor taps End. Ours could tear the queue.
An emergency walk-in and the end of a consultation can hit the same queue in the same second. Here is what a review found in our clinic-queue build, what we changed, and what is still not in production.
- A change that touches several rows should be one transaction.
- The dangerous case is two legitimate actions at once, not one bad actor.
- The fix passed local tests. It is not deployed, and we say so.
- We found this in an audit, not in our test suite, so we test write paths under concurrent load earlier now.
Quick answer
In a review of our clinic-queue platform we found that advancing a queue was a series of separate writes. If a walk-in was inserted at the same moment a doctor ended a consultation, the queue could be left half-updated. We moved it into one transaction under a per-doctor lock. It passed 48 assertions and two concurrency runs locally. It is not in production yet.
The scenario
A clinic is busy. A patient arrives in an emergency. Reception registers them as a walk-in: they go in right after the consultation in progress, and everyone behind renumbers. In the same second the doctor taps End on that consultation, and the queue advances.
Two real actions. One queue.
What the review found
Advancing the queue was a series of separate writes. When two actions overlap, a series of separate writes can interleave: one action reads the queue, the other changes it, and the first writes over what it read. The queue is left with a gap, a duplicate, or someone in the wrong place.
What we changed
We made the queue advance one transaction, under a lock on that one doctor’s queue. Two overlapping actions now run one after the other. Either everything in an action changes or nothing does.
What we haven’t done
The change passed 48 assertions and two concurrency runs locally. It is not in production. We do not call it fixed until it is. Nothing has been proven under real clinic load, and no usage number has been measured.
We found this in an audit, not in our tests. That is the lesson. We now test write paths under concurrent load earlier. The general pattern is explained here, and here is how to test before launch.
The findings and test counts come from our clinic-platform brief and audit notes and are tracked in our claim ledger. No figure comes from a third party.
More by GarunaCDX
Get GarunaCDX news in your inbox.
Launches, new case studies and the industry shifts we are watching — once a month.
