[Regression on closed #273] assignReward's double-payout guard is keyed on (pool, recipient) instead of (pool, issue) — the same issue can still be paid twice

[chonilius]

Problem

#273 ("no guard against being called twice for the same issueId") was closed with this check in MaintenancePoolService.assignReward():

// Guard against double/triple payout for the same issue (#273).
const existingPayment = await this.paymentRepo.findOne({
  where: { recipientId: recipientId ?? null },
});
const existingPoolPayment = await this.paymentRepo
  .createQueryBuilder('payment')
  .innerJoin('payment.escrow', 'escrow')
  .where('escrow.maintenancePoolId = :poolId', { poolId: id })
  .andWhere('payment.recipientId = :recipientId', { recipientId: recipientId ?? null })
  .getOne();
if (existingPoolPayment) {
  throw new ConflictException(`Issue ${issueId} has already received a reward from pool ${id}`);
}

issueId doesn't appear in either query, and Payment has no issue column at all. The guard checks who was paid from this pool, not which issue was rewarded:

1. The same issue can still be paid twice. Call assignReward(pool, issue#1, …, recipientA) and then assignReward(pool, issue#1, …, recipientB), and both succeed. This is the double payout MaintenancePoolService.assignReward has no guard against being called twice for the same issueId — double/triple payout of a single completed task #273 asked to prevent.
2. Anonymous payouts are never guarded. When recipientId is omitted, the query becomes payment.recipientId = NULL, which is never true in SQL. So repeated rewards for the same issue with no recipientId always pass.
3. Legitimate rewards are rejected. A maintainer who fixes two different maintenance issues gets a 409 on the second one, with a misleading message saying that issue was already rewarded.
4. existingPayment is dead code. It's an unscoped query across every payment in the system, whose result is never read, and it costs an extra DB round trip per call.

Suggested fix

• Record the rewarded issue on the payment, for example a nullable Payment.maintenanceIssueId (FK to issues), plus a unique index on (escrowId, maintenanceIssueId).
• Guard on (pool escrow, issueId), and let the unique index close the concurrent-call race.
• Remove the unused existingPayment query.
• Add tests: the same issue with two recipients gets a 409, and two issues for the same recipient both succeed.

Related: #273, #274, #276.

[Ultra-Tech-code]

@Ultra-Tech-code has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hi Maintainer,

I’m a backend and web3 developer with experience in database-backed financial flows, transaction integrity, and security-focused testing. I’d like to work on #458 and fix the maintenance reward idempotency guard.

My approach:

• Add a nullable maintenanceIssueId relationship to Payment and a unique constraint on (escrowId, maintenanceIssueId).
• Change the application-level guard to check the pool escrow and issue being rewarded rather than the recipient.
• Remove the unused global existingPayment query and avoid the extra database round trip.
• Handle the unique constraint as the final protection against concurrent duplicate reward calls.
• Add tests covering the same issue with different recipients, anonymous payouts, separate issues for the same recipient, and concurrent duplicate attempts.

Kindly assign this issue to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ultra-Tech-code to this issue.

[Proxima84-code]

Fix submitted in the PR above. The idempotency guard now filters on (poolId, issueId), Payment records maintenanceIssueId under a composite unique index (escrowId, maintenanceIssueId) to prevent concurrent races, and dead queries were removed. Verified with 20/20 and 58/58 passing unit tests.

[Proxima84-code]

Resolved via PR #472.

• Idempotency guard now checks (poolId, issueId) instead of recipient.
• Added maintenanceIssueId and composite unique index UQ_payment_escrow_maintenance_issue to Payment entity to prevent concurrent double-spend races.
• Handled PostgreSQL unique violation (23505) with balance compensation (assignReward decrements MaintenancePool.balance before poolWithdraw() and never restores it when the withdrawal fails #459).
• Test suites verified: 20/20 in maintenance-pool.service.spec.ts and 58/58 in escrow.service.spec.ts.

[drips-wave]

Congratulations, @Ultra-Tech-code! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @Ultra-Tech-code: 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 🌊