assignReward decrements MaintenancePool.balance before poolWithdraw() and never restores it when the withdrawal fails
Los mantenedores suelen responder en 1 día
@Fabulouz34 ya está trabajando en esto.
Desde el 29/9/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2
- Forks
- 90
- Merge medio
- 31 min
- PR fusionados (30 d)
- 20
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de MergeFi/backend
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
bug security
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
bug testing
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
bug security
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
Todos los issues de MergeFi/backend
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
zapcooking/frontend#946 ·
Los mantenedores suelen responder en 1 día
-
enhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
WiliamRosa/cosmos-semantic-platform#40 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
liberation-data/drivine#733 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
makecindy/cindy#10062 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día