Note: This is deprecated. Use V2.
Local 3-member MongoDB replica set for testing timeouts, transactions, and failure scenarios.
Requirements: Docker, Node.js 18+, mongosh
1. Add hostnames to /etc/hosts:
echo "127.0.0.1 mongo1 mongo2 mongo3" | sudo tee -a /etc/hosts2. Start replica set:
npm install
npm run start:db
npm run init:rs3. Build and run test:
npm run build
npm run run:txConnection string: mongodb://mongo1:27017,mongo2:27017,mongo3:27017/?replicaSet=rs0
Lose majority (WriteConcernFailed):
npm run stop:member -- mongo2
npm run stop:member -- mongo3
npm run run:tx
npm run start:member -- mongo2
npm run start:member -- mongo3Force stepdown:
npm run stepdown
npm run run:txKill member (crash simulation):
npm run kill:member -- mongo2
npm run run:tx
npm run start:member -- mongo2Operation timeout:
export OP_MAXTIME_MS=1
npm run run:txCtrl+C to kill the process.
- Start the no-timeout test:
npm run build
npm run run:tx-notimeout- When you see "💡 STOP NODES NOW! You have 5 seconds...", quickly run:
docker stop mongo2 mongo3-
The script should hang indefinitely at the update operation.
-
Use
Ctrl+Cto kill, then restore:
docker start mongo2 mongo3This reproduces the most common production case where operations complete but commit hangs:
- Start the hang-on-commit test:
npm run build
npm run run:tx-hangcommit-
Wait for the countdown (20 seconds), then when prompted, choose ONE of these:
Option 1: Network Partition (More Realistic)
npm run partition:member -- mongo2 mongo3
This simulates a network partition where nodes stay running but become unreachable (closer to production behavior).
Option 2: Stop Containers (Simpler)
docker stop mongo2 mongo3
This is simpler but the primary detects the failure faster and may throw an error instead of hanging.
-
The script should hang indefinitely at
commitTransaction()! -
Use
Ctrl+Cto kill, then restore:# If you used network partition: npm run restore:member -- mongo2 mongo3 # If you used docker stop: docker start mongo2 mongo3
Key differences in no-timeout tests:
socketTimeoutMS=0(infinite socket timeout)- No
wtimeoutin write concern - No
maxCommitTimeMSon transaction - No
maxTimeMSon operations
This matches typical production configurations where timeouts are not explicitly set, causing commits to hang forever when replica set loses majority.
Environment variables (defaults shown):
W_TIMEOUT_MS=2000 # Write concern timeout
MAX_COMMIT_MS=1500 # Transaction commit timeout
OP_MAXTIME_MS=1000 # Operation timeoutdocker compose down -v