Found in #448's Synthea sanity pass, transaction-ingestion leg.
Per FHIR R4 http.html#create, on POST "the server ignores the id provided in the resource" and assigns a new one. HFS instead persists the client-supplied id and returns 409 resource already exists when a second POST carries the same id:
- Direct:
POST /Organization with id: dup-test → 201; repeat → 409.
- In the wild: Synthea transaction bundles share Organizations/Practitioners across patients (same ids, plain POST entries, no
ifNoneExist). The first patient bundle commits; every later bundle referencing a shared org fails whole with Transaction failed at entry N: resource already exists. 1 of 10 sample bundles failed this way.
Options: assign server ids on POST per spec (breaking for anyone relying on client ids), or keep honoring client ids but treat POST-with-existing-id as update/no-op semantics deliberately and document the deviation. Either way the current combination breaks standard Synthea ingestion by transaction.
All three findings link back to #448.
Found in #448's Synthea sanity pass, transaction-ingestion leg.
Per FHIR R4 http.html#create, on
POST"the server ignores the id provided in the resource" and assigns a new one. HFS instead persists the client-suppliedidand returns409 resource already existswhen a second POST carries the same id:POST /Organizationwithid: dup-test→ 201; repeat → 409.ifNoneExist). The first patient bundle commits; every later bundle referencing a shared org fails whole withTransaction failed at entry N: resource already exists. 1 of 10 sample bundles failed this way.Options: assign server ids on POST per spec (breaking for anyone relying on client ids), or keep honoring client ids but treat POST-with-existing-id as update/no-op semantics deliberately and document the deviation. Either way the current combination breaks standard Synthea ingestion by transaction.
All three findings link back to #448.