Problem
In MaintenancePoolService.assignReward(), the #274 atomic check-and-decrement runs before the on-chain payout:
const updateResult = await this.poolRepo
.createQueryBuilder()
.update(MaintenancePool)
.set({ balance: () => `balance - :amount` })
.where('id = :id AND balance >= :amount', { id, amount: Number(amount) })
...
.execute();
if (updateResult.affected === 0) throw new BadRequestException(...);
const payment = await this.escrowService.poolWithdraw(pool.escrowId, amount, recipientAddress, recipientId);
return payment;poolWithdraw() has several ways to throw after the balance has already been reduced:
assertLocked(escrow)assertValidAmount(amount)assertRecipientsMatchUsers(...): a recipientAddress that doesn't match recipientId's wallet- a Soroban simulate, send or poll failure inside
invokeOnLockedEscrow
- the final
paymentRepo.save
None of these paths gives the reserved amount back, so every failed reward permanently shrinks the pool's DB balance, even though no USDC left the contract. Over time MaintenancePool.balance drifts below the real on-chain balance. Rewards then start failing with "exceeds pool balance" while funds are still in escrow, and there's no admin path to reconcile.
Suggested fix
- Wrap the payout in try/catch. On failure, restore the reservation with
increment({ id }, 'balance', Number(amount)) and rethrow.
- Only do that when the on-chain call is known not to have gone through.
invokeOnLockedEscrow's state distinguishes "never submitted" from "submitted, outcome unknown".
- Move the cheap validation (recipient/user match, amount) before the decrement so bad input never touches the balance.
- Add tests with
poolWithdraw rejecting that assert the pool balance is unchanged.
Related: #51, #274 (introduced the reserve-first ordering), #163.
Problem
In
MaintenancePoolService.assignReward(), the #274 atomic check-and-decrement runs before the on-chain payout:poolWithdraw()has several ways to throw after the balance has already been reduced:assertLocked(escrow)assertValidAmount(amount)assertRecipientsMatchUsers(...): arecipientAddressthat doesn't matchrecipientId's walletinvokeOnLockedEscrowpaymentRepo.saveNone of these paths gives the reserved amount back, so every failed reward permanently shrinks the pool's DB balance, even though no USDC left the contract. Over time
MaintenancePool.balancedrifts below the real on-chain balance. Rewards then start failing with "exceeds pool balance" while funds are still in escrow, and there's no admin path to reconcile.Suggested fix
increment({ id }, 'balance', Number(amount))and rethrow.invokeOnLockedEscrow's state distinguishes "never submitted" from "submitted, outcome unknown".poolWithdrawrejecting that assert the pool balance is unchanged.Related: #51, #274 (introduced the reserve-first ordering), #163.