Date: 2026-05-29
Time: 14:26
I'll explain the file based on what's visible in the test code and what it reveals about the system under test.
two-phase-commit/twophasecommit.py — The implementation behind all these tests: coordinator state machine, participant locking, the log, and the recovery protocoltwo-phase-commit/twophasecommit.py:TwoPhaseCommitSystem.execute — The main entry point: how it orchestrates prepare/commit/abort across participantstwo-phase-commit/twophasecommit.py:Coordinator.recover — How the coordinator replays its write-ahead log to finish in-flight transactions after a crash2pc-blocking-problem — The classic 2PC limitation where participants holding locks are blocked if the coordinator crashes after prepare but before commit — testparticipantrecovery hints at this but doesn't fully exercise ittwo-phase-commit/testertest2pc.py — The meta-test layer: how this project validates that the test suite itself covers the right protocol guarantees2pc-abort-guarantees-no-side-effects — When any participant is unavailable, execute() returns "aborted" and no participant's state is modified, even for participants that were available2pc-uses-key-level-locking — Participants lock at key granularity during prepare; a second transaction touching a locked key will abort rather than wait2pc-locks-released-on-both-paths — Locks held by a transaction are released regardless of whether it commits or aborts, preventing deadlocks across sequential transactions2pc-coordinator-recovery-replays-commit — A coordinator with a "committing" log entry will re-send commit decisions to all participants during recover(), ensuring crash-after-decision still completes2pc-result-dict-not-exceptions — The protocol communicates outcomes via {"outcome": "committed"|"aborted", "reason": ...} return values, never via exceptions