- Shipped
- August 25, 2026 at 4:25 PM UTC
- Author
- Kamo
- Commit
- 4363c53
Phase 1 resolves every conditional reference and urn:uuid placeholder and touches nothing. Phase 2 writes and reads nothing. The split is the entire point. The naive implementation interleaves them — conditional-create a Patient, read its id back, reference it from the Observation, write that. On YugabyteDB a SELECT after a write in the same transaction triggers a read restart surfaced as SQLSTATE 40001. It fails only under concurrency, so it passes every test, ships, and then presents in production as a random deadlock. A retry loop then appears to fix it while only winning the race more often, converting an error into occasional silent slowness that stays for years. Splitting the phases makes it impossible rather than rare. That is pinned by a test asserting no resolve ever follows a write, and it is mutation-proven: rewriting the executor as the naive per-entry loop failed with the actual interleaving printed — RESOLVE:Patient, WRITE:Patient, WRITE:Observation, RESOLVE:Condition. A conditional reference matching more than one resource is a 412, never "pick the first". Duplicate patient records are ordinary rather than theoretical, and picking silently attaches an observation, an order or a note to whichever duplicate the index returned. The server does not guess which record clinical data belongs to. Because resolution is a separate phase, an ambiguous conditional aborts before ANY write happens, which is what makes the Bundle genuinely atomic rather than **************** Bundles above 500 entries are refused with 413 rather than attempted. One resource write already spans ten-plus tablets, so an unbounded Bundle is an unbounded distributed transaction: it would lock a large part of the cluster, hold those locks, and very likely time out anyway having blocked everyone else's writes. Splitting is what the client would have to do regardless. 1700 tests green.