You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :
(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.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
The way
FeignClientFactoryBean
handles configuration fordismiss404
, it will enable it as soon as any config sets it totrue
.The default is applied first, so if it has
decode404
that will enabledismiss404
. Applying the client-specific config that hasdecode404
set to false, will not change the value ofdismiss404
back.Relevant code :
spring-cloud-openfeign/spring-cloud-openfeign-core/src/main/java/org/springframework/cloud/openfeign/FeignClientFactoryBean.java
Lines 294 to 298 in 0d7e0e1
Sample
Not able to make a full sample right now, I will try to describe it as best as I can :
Clients :
application.yml
:(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
todismiss404
, butclientWithout404
not to. In our case we have a lot of clients from internal libraries expecting the default to betrue
, and one client where this is not the case. Configuring them all individually is a working workaround but quite an error-prone chore.The text was updated successfully, but these errors were encountered: