fix: namespace idempotency keys by principal (#6 item D) #13
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/issue-6-idempotency-principal"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #6 (the deferred Item D; the other four landed in #12).
content_hash(UNIQUE) was the idempotency key as-is, so two principals reusing one key collapsed to first-writer-wins -- the second caller silently got back the first principal's transaction (a write-shadowing hazard).Fix
Namespace the idempotency key by the posting principal (falling back to the posting role when no principal is supplied) in both
postTransactionandeditTransaction, via a sharedWriterExecutor.namespacedContentHash. The pre-check lookup uses the same namespaced value, so a same-principal retry stays idempotent.Pre-migration rows keep their bare hashes; the namespaced space never collides with them, so the UNIQUE constraint still holds and no data migration is needed.
Test
testIdempotencyKeyNamespacedByPrincipal: two principals reusing one key get distinct transactions, while a same-principal retry returns the same transaction (still idempotent).Full SwiftPM suite: 189 passing, 0 failures (no regressions in
AgentAttributionTestsor the MCP propose/commit idempotency tests).