Epic: Phase 2 — Dual Primary Write Mode #162
Labels
No labels
Blocked
Duplicate
MoSCoW/Could Have
MoSCoW/Must Have
MoSCoW/Should Have
Points/1
Points/13
Points/2
Points/21
Points/3
Points/5
Points/8
Priority/Backlog
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
State/Completed
State/In progress
State/In review
State/Paused
State/Unverified
State/Verified
State/Wont Do
Type/Bug
Type/Epic
Type/Feature
Type/Legendary
Type/Task
Type/Testing
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Depends on
#13 Production-Ready Event Sourcing
aethyr/Aethyr
#164 Build GDBM vs ES state verification tooling
aethyr/Aethyr
Reference: aethyr/Aethyr#162
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Background and Context
In Phase 2 of the GDBM-to-ES migration, both stores must succeed for a write to complete. If the ES write fails after a successful GDBM write, the GDBM write must be rolled back. This ensures the two stores never diverge. Verification tooling confirms store consistency before transitioning to Phase 3.
Demonstrable Outcome
When
es_write_mode: :dual_primary, any ES failure triggers GDBM rollback. A verification tool compares all GDBM objects against ES aggregates and reports zero discrepancies.Acceptance Criteria
:dual_primarymode implemented with rollback