Skip to content

FeignClientFactoryBean dismiss404 default config overrides client-specific config #1005

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Bluexin opened this issue Mar 19, 2024 · 1 comment
Assignees
Labels
bug Something isn't working
Milestone

Comments

@Bluexin
Copy link

Bluexin commented Mar 19, 2024

Describe the bug
The way FeignClientFactoryBean handles configuration for dismiss404, it will enable it as soon as any config sets it to true.
The default is applied first, so if it has decode404 that will enable dismiss404. Applying the client-specific config that has decode404 set to false, will not change the value of dismiss404 back.
Relevant code :

if (config.getDismiss404() != null) {
if (config.getDismiss404()) {
builder.dismiss404();
}
}

Sample
Not able to make a full sample right now, I will try to describe it as best as I can :
Clients :

@FeignClient(name = "clientWith404")
interface MyFeignClientWith404

@FeignClient(name = "clientWithout404")
interface MyFeignClientWithout404

application.yml :

feign:
  client:
    config:
      default:
        decode404: true
      clientWithout404:
        decode404: false

(note: this sample might be a bit mixed up between the older version and the new one, I see some changes in the name to dismiss404 but the code handling the config is the same)

From this configuration, I expect clientWith404 to dismiss404, but clientWithout404 not to. In our case we have a lot of clients from internal libraries expecting the default to be true, and one client where this is not the case. Configuring them all individually is a working workaround but quite an error-prone chore.

@OlgaMaciaszek OlgaMaciaszek self-assigned this Mar 19, 2024
@OlgaMaciaszek OlgaMaciaszek moved this to In Progress in 2023.0.1 Mar 21, 2024
@OlgaMaciaszek OlgaMaciaszek added this to the 4.1.1 milestone Mar 21, 2024
@OlgaMaciaszek
Copy link
Collaborator

Thanks @Bluexin, I was able to reproduce it. Wil fix it.

@github-project-automation github-project-automation bot moved this from In Progress to Done in 2023.0.1 Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Status: Done
Development

No branches or pull requests

3 participants