Repository navigation
assignReward decrements MaintenancePool.balance before poolWithdraw() and never restores it when the withdrawal fails #459
Description
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(...): arecipientAddressthat doesn't matchrecipientId'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
poolWithdrawrejecting that assert the pool balance is unchanged.
Related: #51, #274 (introduced the reserve-first ordering), #163.
Activity
Fabulouz34 commentedon Sep 27, 2026
@Fabulouz34 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @Fabulouz34 to this issue.
Ultra-Tech-code commentedon Sep 27, 2026
@Ultra-Tech-code has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ultra-Tech-code to this issue.
Proxima84-code commentedon Sep 28, 2026
I have submitted a clean fix in PR above. Wrapped
poolWithdraw()in a compensatingtry/catchblock that atomically restores the decremented pool balance viapoolRepo.increment()whenever on-chain execution or persistence fails. Verified with 17/17 passing unit tests.Proxima84-code commentedon Sep 28, 2026
I have submitted a clean fix in PR above. Wrapped
poolWithdraw()in a compensatingtry/catchblock that atomically restores the decremented pool balance viapoolRepo.increment()whenever on-chain execution or persistence fails. Verified with 17/17 passing unit tests.drips-wave commentedon Sep 29, 2026
Congratulations, @Fabulouz34! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.
🧑💻 @Fabulouz34: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.
Warning
When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.
🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.
🌊 Happy Wave 🌊
fix(maintenance-pool): restore reserved balance on failed escrow with…