[
https://issues.apache.org/jira/browse/FINERACT-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18067581#comment-18067581
]
Deepak Kumar S S commented on FINERACT-2485:
--------------------------------------------
Thanks for redirecting this here, [~aleks] .
Just to clarify — my comment on FINERACT-2169 was a quick observation,
not the full design. What I'm actually proposing in FINERACT-2485 is
different: a dedicated idempotency_request table with a UNIQUE constraint
on (idempotency_key, tenant_id), not touching CommandSource at all.
On your *performance concern* — completely valid. The filter has two paths:
if no Idempotency-Key header is present, it exits immediately with zero DB
cost (target under 1ms). Only keyed requests hit the DB, and only on first
occurrence. Duplicates get the cached response back without going near
business logic. The reason I avoided the CommandSource approach is exactly
what you pointed out — exception-driven control flow on every write is too
expensive.
For a *default implementation:* if no header is sent, it passes through as
normal. The whole thing is behind a Global Configuration flag that defaults
to false, so existing deployments see no change unless they explicitly
enable it.
On *replaceability* — open to it. If a pluggable IdempotencyStore interface
makes more sense, I'd rather nail down the interface design with you during
Community Bonding before writing any code.
On *content-based key generation* — the current design relies on
client-provided keys. I deliberately avoided server-side content hashing
because of the attribute ordering problem you're pointing at. That said,
if it's useful as a fallback (TreeMap sort → canonical JSON → SHA-256),
I can add it as an opt-in strategy. Not the default though.
Would it help if I wrote up an ADR covering these decisions before
implementation starts?
> [GSoC 2026] [POC] Standardize and Harden Transaction Idempotency for Savings
> and Loans
> --------------------------------------------------------------------------------------
>
> Key: FINERACT-2485
> URL: https://issues.apache.org/jira/browse/FINERACT-2485
> Project: Apache Fineract
> Issue Type: Sub-task
> Reporter: saifulhuq
> Priority: Major
> Labels: poc, security
>
> *Goal:* Standardize idempotency enforcement to prevent replay attacks in core
> financial modules. *Implementation Strategy (Addressing James Dailey's
> feedback):*
> # *Opt-In Architecture:* New logic will be behind a Global Configuration
> flag. Default remains legacy behavior to ensure 100% backward compatibility.
> # *Phased Approach:* Audit existing {{m_portfolio_command_source}} usage and
> bridge gaps in the Savings module first.
> # *Testing:* Implementation of integration tests simulating network
> failures/retries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
