[
https://issues.apache.org/jira/browse/FINERACT-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Kang updated FINERACT-2501:
----------------------------------
Description:
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 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.
However, after some investigation, 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. Since we are
hardcoding these method names into our tests, this can create issues where
tests need to be rewritten every time a new endpoint is added.
For example, in my tests, when a new retrieveAll() endpoint is added,
retrieveAll35() can shift from referencing the savingsproductsApiResource to
some other ExampleApiResource.
Below I add a new dummy endpoint, you can see 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.
I linked 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 would not affect the rest of the codebase, but
fix the issue of allowing our HTTP clients to use stable method names from now
on.
was:
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 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.
However, after some investigation, 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. Since we are
hardcoding these method names into our tests, this can create issues where
tests need to be rewritten every time a new endpoint is added.
For example, in my tests, when a new retrieveAll() endpoint is added,
retrieveAll35() can shift from referencing the savingsproductsApiResource to
some other ExampleApiResource.
Below I add a new dummy endpoint, you can see 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.
I linked 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.
> 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 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.
> However, after some investigation, 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. Since we are hardcoding these method names into our tests, this can
> create issues where tests need to be rewritten every time a new endpoint is
> added.
> For example, in my tests, when a new retrieveAll() endpoint is added,
> retrieveAll35() can shift from referencing the savingsproductsApiResource to
> some other ExampleApiResource.
> Below I add a new dummy endpoint, you can see 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.
> I linked 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 would not affect the rest of the
> codebase, but fix the issue of allowing our HTTP clients to use stable method
> names from now on.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
