Hi Thank you for raising this topic!
In my understanding, if no idempotency key is provided, we should not enforce idempotent behavior. While I understand where the fallback logic is coming from, I am hesitant to go on that path: “Same payload” is not always the same business intent. shifts idempotency responsibility from the client contract to server inference it can mean blocking a valid transaction For these reasons, I am not sure we should enforce this as default fallback. Maybe it is as an optional thing would be better? Regards, Adam > On Apr 9, 2026, at 2:07 PM, elnafateh <[email protected]> wrote: > > Hi everyone, > > I would like to raise a discussion regarding idempotency handling in > Fineract, specifically when a client does not provide an idempotency key. > > Problem > > Currently, if a client omits the idempotency key, the system may generate a > random UUID per request. In retry scenarios, this can lead to duplicate > processing of the same logical operation. > > A typical scenario: > > Client sends a request (e.g., funds transfer) > > Server processes and commits successfully > > Client does not receive the response (e.g., network timeout) > > Client retries the same request without an idempotency key > > A new UUID is generated → request is treated as a new operation > > This can result in unintended duplicate transactions (e.g., double spending). > > Proposal > > Instead of generating a random UUID, generate a deterministic idempotency key > based on: > > Request payload > > Relevant context (e.g., clientId, entityName,ActionName etc) > > Optional bounded time window > > This ensures that repeated identical requests map to the same idempotency > key, even when the client does not explicitly provide one. > > Open Questions > > Should the system enforce idempotency even when the client does not provide a > key? > > Is deterministic key generation an acceptable fallback strategy? > > Are there concerns around edge cases (e.g., payload variations, time window > constraints)? > > I would really appreciate feedback on whether this problem is valid in the > context of Fineract and if this approach aligns with the project’s design > principles. > > Thanks, > Lukman Fateh >
