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
Does it make sense to pass to the StoreProvider a callback that runs on every request with the status code response?
The idea is to clean the backup as soon as we get a 401 response from unleash.
Knowing that the request was forbidden, i think it makes sense to clean it.
What are your thoughts on this?
Thank you!
Background
We had some problems while migrating our unleash between two kubernetes clusters. We didnt understand at first, why even after the api token was changed, the requestes from unleash-client-node were still passing.
We figured out that the backup was returning the responses.
Although the backup is a great feature for resilience, for us, it didnt make much sense to use the backup even after a 401 response.
Solution suggestions
Inject a request callback into the StoreProvider that can monitor the requests and take action depending on the response, so developers could provide a functionality to clean the backup depending on the status code.
Although it seems this could be a nice feature for the default storage provider.
The text was updated successfully, but these errors were encountered:
Hi @jojovem - Would you be willing to write a PR implementing this yourself? I think your idea makes sense, but we don't have any free engineers to implement this at the moment
Describe the feature request
Hi all!
Does it make sense to pass to the StoreProvider a callback that runs on every request with the status code response?
The idea is to clean the backup as soon as we get a 401 response from unleash.
Knowing that the request was forbidden, i think it makes sense to clean it.
What are your thoughts on this?
Thank you!
Background
We had some problems while migrating our unleash between two kubernetes clusters. We didnt understand at first, why even after the api token was changed, the requestes from unleash-client-node were still passing.
We figured out that the backup was returning the responses.
Although the backup is a great feature for resilience, for us, it didnt make much sense to use the backup even after a 401 response.
Solution suggestions
Inject a request callback into the StoreProvider that can monitor the requests and take action depending on the response, so developers could provide a functionality to clean the backup depending on the status code.
Although it seems this could be a nice feature for the default storage provider.
The text was updated successfully, but these errors were encountered: