Currently harmless because the route returns a fake hash, but this is exactly the kind of gap that becomes a real-money bug the moment the "make sendPayment real" issue above ships. A double-click, a client retry after a slow response, or a network blip causing a client-side resend all need to be idempotent against the same logical payment.
Definition of done:
- Client-generated idempotency key required on the request, stored server-side against the resulting transaction
- Duplicate key within a defined window returns the original result instead of re-submitting
- Test simulating a double-submit confirms only one on-chain operation occurs
Before opening a PR for this issue, read CONTRIBUTING.md.
This is not a starter-issue. The Definition of done above is the full
acceptance criteria, not a subset to sample from — a PR that addresses part
of it is an unfinished issue, not a smaller one. Your PR must include, in
the PR description itself:
PRs missing these will be sent back before review, not reviewed and rejected — please do this up front.
Currently harmless because the route returns a fake hash, but this is exactly the kind of gap that becomes a real-money bug the moment the "make sendPayment real" issue above ships. A double-click, a client retry after a slow response, or a network blip causing a client-side resend all need to be idempotent against the same logical payment.
Definition of done:
Before opening a PR for this issue, read CONTRIBUTING.md.
This is not a starter-issue. The Definition of done above is the full
acceptance criteria, not a subset to sample from — a PR that addresses part
of it is an unfinished issue, not a smaller one. Your PR must include, in
the PR description itself:
PRs missing these will be sent back before review, not reviewed and rejected — please do this up front.