Hi James, Understood. Those are critical constraints.
To address the **Backwards Compatibility** and **Non-Triviality**: My proposal is to implement this strictly as an **Opt-In POC** behind a Global Configuration (similar to the 'Force Withdrawal' pattern in PR #5465). 1. **Default Behavior:** The system behaves exactly as it does today (Legacy Idempotency). Zero disruption to existing users. 2. **Strict Mode (POC):** Only when the kconfig is enabled does the new "Strict Idempotency" logic engage. This isolates the risk and allows us to test the "Strict Mode" without breaking any existing API contracts. Regarding Mentorship: Since I am working professionally (SDE 1), I am comfortable driving the implementation with minimal hand-holding, requiring only architectural review (similar to the review process for PR #5465). If this "Opt-In POC" approach is acceptable, I will create the ticket as a "Draft/POC" item. Best, Mohammed On Mon, 9 Feb, 2026, 6:37 pm James Dailey, <[email protected]> wrote: > Ok. Understood but… > > We would need a mentor who is expert enough in this to be involved. > > Also, a key principle is to keep backwards compatibility for existing > users of current api idempotency. This makes it non trivial. > > I believe that also we want to make it clear that these are POCs per the > write ups > > Sent from Gmail Mobile > > > On Mon, Feb 9, 2026 at 1:59 PM Mohammed Saifulhuq < > [email protected]> wrote: > >> Hi James and Community, >> >> Responding to the call for additional GSoC ideas: >> >> I would like to propose a project focused on **Transaction Security & >> Idempotency Hardening** (aligning with the 2026 Security theme). >> >> **Context:** >> While working on the 'Force Withdrawal' Core Engine (PR #5465 >> <https://github.com/apache/fineract/pull/5465>), I observed that while >> Fineract has an existing mechanism for command tracking >> (`m_portfolio_command_source`), its enforcement is inconsistent across >> different APIs. This leaves specific transaction paths vulnerable to >> "Replay Attacks" (double-charging) during network timeouts. >> >> **Proposed Scope (Manageable & Targeted):** >> 1. **Audit:** Map the current state of Idempotency enforcement across >> Savings and Loan transaction APIs. >> 2. **Standardize:** Refactor the existing `IdempotencyKey` pattern to >> ensure it is strictly enforced for all critical financial transactions >> (starting with Savings). >> 3. **Harden:** Add Integration Tests to simulate network replays and >> verify that the system correctly rejects duplicate requests. >> >> I believe this fits the "Small, Manageable, High-Impact" criteria.. >> >> If this aligns with the roadmap, I would be happy to create a JIRA ticket >> (e.g., FINERACT-24XX) and draft the detailed proposal. >> >> Best regards, >> Mohammed Saifulhuq >> (Contributor, PR #5465 <https://github.com/apache/fineract/pull/5465>) >> >
