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: 1. Client sends a request (e.g., funds transfer) 2. Server processes and commits successfully 3. Client does not receive the response (e.g., network timeout) 4. Client retries the same request without an idempotency key 5. 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
