[Backend] Idempotency middleware has a concurrency race that allows duplicate money-moving submissions

[grantfox-oss]

Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0

Why this matters

src/middleware/idempotency.ts only writes the cached response on the res 'finish' event (lines 74-91), so two concurrent requests sharing one Idempotency-Key both miss the cache check (line 30) and both execute the handler. On /loans/:loanId/repay and /pool/submit this can submit the same signed transaction to Stellar twice.

Acceptance criteria

• Reserve the idempotency key atomically before running the handler (e.g. cacheService NX set) so a second concurrent request is rejected or made to wait
• Return a 409 or a deterministic 'in progress' response for a key whose first request has not finished
• Persisted response is still returned for completed keys, preserving current HIT behavior
• Add a concurrency test that fires two simultaneous requests with the same key and asserts the handler runs once

Files to touch

• src/middleware/idempotency.ts
• src/services/cacheService.ts
• src/routes/loanRoutes.ts
• src/routes/poolRoutes.ts

Out of scope

• Changing the 24h TTL policy
• Adding idempotency to GET endpoints

[Akpolo]

I have worked on similar open source issues before, so I am happy to take this one. My plan is to reproduce the current behavior first, make the fix in clean commits, and link the PR back to the issue. I should be able to submit in about 3 days.

[grantfox-oss]

🦊 GrantFox — @Akpolo 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 #1)
2. Your PR will be reviewed by the LabsCrypt maintainers

Good luck! Track your progress on GrantFox.