[
https://issues.apache.org/jira/browse/FINERACT-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18060425#comment-18060425
]
Ambika commented on FINERACT-2501:
----------------------------------
Hi Edward,
I’ve been following the discussion on the dev mailing list regarding this
issue. This looks like an important improvement to ensure stable Feign client
method names.
I’d be happy to contribute to this effort. If helpful, I can start by adding
explicit {{operationId}} values for a specific module (for example, Portfolio
or Infrastructure) to help parallelize the work.
Please let me know which module would be best to begin with.
> Add operationIds and refactor feign methods to fix unstable deduplication
> numbers generated by swagger
> ------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2501
> URL: https://issues.apache.org/jira/browse/FINERACT-2501
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Edward Kang
> Assignee: Edward Kang
> Priority: Major
> Attachments: Screenshot 2026-02-23 at 10.04.14 AM.png,
> image-2026-02-23-10-02-00-868.png
>
>
> I noticed that we use a Swagger and OpenApi generator for endpoint access
> with Feign client, which creates methods that we can call instead of having
> to construct endpoints, JSON, etc. ourselves. While I was using this, I
> noticed that simply calling the method names in SavingsProductsApiResource
> doesn’t work. It seems we must call the methodName + deduplication number
> that is assigned by Swagger (ie. the deduplicated operationId). So far, this
> is expected behavior.
> After some investigation though, I think this might be an issue down the line
> as we build out more tests in Cucumber. This is because when new endpoints
> are added with the same method name, they can actually reorder the
> deduplication numbers in operationId, causing our Feign client calls to break.
> For example, when a new endpoint is added, retrieveAll35() can shift from
> referencing the savingsproductsApiResource to some ExampleApiResource, or
> another resource that also uses retrieveAll().
> I tested it out locally and found that if I add a new dummy endpoint, the
> deduplication number of SavingsProductsApiResource’s retrieveAll() goes from
> retrieveAll35() to retrieveAll36(), meaning the new endpoint is inserted in
> the middle somewhere.
> It is also telling that the recent loan-originators endpoint added a
> retrieveAll, but it got set as retrieveAll28. This means it got inserted in
> the middle since retrieveAll1 and retrieveAll40 exist.
> Below is a picture of loan-originator's retrieve all. It shows dedupe number
> 29. In your build, without my added endpoint, you should look in
> fineract.yaml and find that it is retrieveAll_28. Without my new dummy
> endpoint, a rebuild sets it back to retrieveAll_28 to confirm this.
> !image-2026-02-23-10-02-00-868.png!
> New Build without new endpoint.
> !Screenshot 2026-02-23 at 10.04.14 AM.png!
> I am proposing adding operationId to @Operation in each ApiResource, along
> with a refactor of deduplicated method names on currently implemented Feign
> client calls to fix this issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
