mirror of
https://github.com/Such-Software/wownerogue.git
synced 2026-10-19 15:18:33 +02:00
feat: initial batch payout logic and output splitting script added
This commit is contained in:
@@ -340,6 +340,28 @@ WantedBy=multi-user.target
|
||||
|
||||
---
|
||||
|
||||
## Wallet Output Management
|
||||
|
||||
Wownero (and Monero) lock change outputs for several blocks after spending. If the wallet has only one large output and multiple payouts fire in quick succession, the second payout will fail because the change output from the first is still locked.
|
||||
|
||||
**Solution**: Pre-split wallet outputs into many smaller ones. The game server includes a CLI tool for this:
|
||||
|
||||
```bash
|
||||
# Preview what would happen (no transaction sent)
|
||||
node scripts/splitOutputs.js --amount 10 --count 30 --dry-run
|
||||
|
||||
# Split into 30 outputs of 10 WOW each (requires ~300 WOW + fees)
|
||||
node scripts/splitOutputs.js --amount 10 --count 30
|
||||
```
|
||||
|
||||
This creates 30 independently-spendable outputs, allowing up to 30 concurrent payouts before any output locking becomes an issue.
|
||||
|
||||
**When to re-split**: As payouts go out, outputs get consumed and consolidated via change. Periodically check the wallet and re-split when the number of spendable outputs drops low. The server also batches payouts that happen within 5 seconds of each other into a single transaction to conserve outputs.
|
||||
|
||||
**Recommended setup**: After initial wallet funding, run the split script. For a game with typical traffic, 20-30 outputs of 10 WOW each provides good concurrency headroom.
|
||||
|
||||
---
|
||||
|
||||
## Monitoring
|
||||
|
||||
### Check Service Status
|
||||
|
||||
@@ -87,6 +87,16 @@
|
||||
- [x] **Admin UI**: Full dashboard at `/admin.html` with charts and tables
|
||||
- [x] **Payout Retry**: Manual retry button in admin dashboard
|
||||
|
||||
## Payout Reliability (Feb 2026)
|
||||
- [x] **Fire-and-Forget INSERT Fix**: `_insertGameRecord` now awaited, prevents race conditions ✅
|
||||
- [x] **Double Game-Over Prevention**: `activeGames.delete()` moved before any `await` in `handleGameOver` ✅
|
||||
- [x] **DB-Level Duplicate Payout Prevention**: Unique partial index on `payouts(game_id)` (migration 012) ✅
|
||||
- [x] **Payout Address Locking**: Address captured at game start, stored in `games.payout_address` ✅
|
||||
- [x] **Dead Code Removal**: Deleted unused `processGameCompletion()` method ✅
|
||||
- [x] **Same-Block Payout Batching**: Payouts within 5-second window batched into one `transfer_split` call ✅
|
||||
- [x] **Output Splitting Script**: `scripts/splitOutputs.js` for wallet output management ✅
|
||||
- [x] **transfer_split**: Switched from `transfer` to `transfer_split` for output resilience ✅
|
||||
|
||||
## Pre-Production Testing Checklist
|
||||
|
||||
### Security Verification
|
||||
@@ -120,6 +130,8 @@
|
||||
- [x] **Payout Retry Queue**: Automatic retry mechanism via `payoutRetryService.js` ✅
|
||||
- [x] **Address Validation**: Wallet RPC `validate_address` method ✅
|
||||
- [ ] **Redis Rate Limiting**: Replace in-memory rate limiter with Redis for persistence across restarts
|
||||
- [ ] **Full Payout Batching**: Implement configurable batch intervals beyond same-block 5-second window
|
||||
- [ ] **Wallet Health Monitoring**: Track spendable output count, alert when outputs are low
|
||||
|
||||
### Frontend
|
||||
- [ ] **Socket Reconnection**: Add `reconnect` and `disconnect` handlers to restore state after connection loss
|
||||
|
||||
Reference in New Issue
Block a user