[CRITICAL] processRewardClaim has no DB transaction — reward lost or double-spent

[DeFiVC]

Description

processRewardClaim in src/modules/rewards/reward.service.ts:67-78 marks rewardClaimed: true (line 67-70), then separately increments credits (line 72-77) with two independent DB calls (no transaction wrapping).

If the process crashes or the second update fails after the first succeeds:

• rewardClaimed is true but credits never added → user permanently loses the reward (retry sees rewardClaimed === true on line 37 and skips)
• If on-chain claim succeeded but DB update fails → retry attempts second on-chain claim → double-spend

Impact

Inconsistent state between on-chain and DB with no recovery path.

File

src/modules/rewards/reward.service.ts:67-78

Suggested Fix

Wrap the rewardClaimed update and credit increment in a single DB transaction using db.transaction().

[AbelOsaretin]

I'd like to work on this issue.
The processRewardClaim function in src/modules/rewards/reward.service.ts:67-78 performs two separate database operations — setting rewardClaimed: true (lines 67-70) and incrementing the user's credits (lines 72-77) — without a wrapping transaction. If the process crashes or the second update fails after the first succeeds, the reward is permanently lost because the retry guard on line 37 sees rewardClaimed === true and skips. Worse, if the on-chain claim succeeds but the DB update fails, a retry triggers a second on-chain claim, causing a double-spend.
My approach
Wrap the rewardClaimed update and the credit increment in a single db.transaction() block so that both operations either succeed together or roll back entirely. This ensures atomicity between the two DB writes, preventing the inconsistent state where one operation commits and the other does not.
Implementation plan

1. Wrap both DB operations in a transaction
   • Replace the two independent calls in src/modules/rewards/reward.service.ts:67-78 with a single db.transaction() block
   • Move the rewardClaimed: true update (lines 67-70) and the credit increment (lines 72-77) inside the transaction callback
   • Ensure the transaction commits only if both operations succeed, and rolls back on any failure
2. Handle transaction failure explicitly
   • Add a try/catch around the transaction block so that if it fails, the on-chain claim state is not left in a half-committed state
   • Log the transaction failure for observability
   • Return an appropriate error response to the caller indicating the claim was not processed
3. Add an idempotency guard before the transaction
   • Before entering the transaction, check rewardClaimed status (the existing check on line 37)
   • This prevents redundant transaction attempts on retry when the claim already succeeded on-chain but the DB update failed
4. Add tests for partial failure scenarios
   • Test that when the credit increment fails after the rewardClaimed update is attempted, the entire transaction rolls back and rewardClaimed remains false
   • Test that a retry after a partial failure succeeds atomically on the second attempt
   • Test the happy path where both operations succeed and commit together
     Impact

• Prevents permanent reward loss caused by partial DB updates where rewardClaimed is set to true but credits are never credited.
• Eliminates double-spend risk where a retry triggers a second on-chain claim due to inconsistent DB state.
• Ensures data consistency between the rewardClaimed flag and the user's credit balance, which is critical for any financial or reward system.
  I'm ready to start immediately and can have a PR up within a reasonable timeline. Happy to adjust the plan if you have preferences on any of the details.

[Clement-coder]

Hello, I'm a Full Stack Blockchain, Mobile, and Software Engineer with experience building scalable applications, smart contracts, APIs, and modern user-focused products.

I've reviewed this issue and understand the requirements and expected outcome. My background allows me to quickly analyze problems, implement efficient solutions, and maintain high code quality throughout development. I'm confident in my ability to deliver a clean, well-tested, and maintainable solution, and I'd be excited to contribute to this project.

[Mitch5000]

Hi Boss... I can handle this professionally and make sure that your issue is closed quickly without errors.

[suleimanjem-hash]

I'd like to work on the [Refactor] Extract hardcoded Stellar network passphrases into environment variables issue. I have experience with configuration management and backend development, and I can implement this refactor following best practices. I'll ensure the changes are clean, secure, and well-tested before submitting a PR.

[grantfox-oss]

🦊 GrantFox — @AbelOsaretin has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #25)
2. Your PR will be reviewed by the ChainLearnOfficial maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@AbelOsaretin's PR #42 was approved and merged by @DeFiVC.

🏆 @AbelOsaretin: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (258 total points). Track your full progress on GrantFox.

👏 Great work, @AbelOsaretin! Keep contributing to ChainLearnOfficial.