[
https://issues.apache.org/jira/browse/FINERACT-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18060738#comment-18060738
]
Ambika commented on FINERACT-2501:
----------------------------------
Hi Edward, I don’t have an @apache.org email, so it looks like I’ll need a
guest invitation to join the ASF Slack workspace. Could you please invite
me? I can share my email address if needed.
Thank you.
> 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)
