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
Ideally this would be configurable to adjust based on the usage of the store.
Describe the solution you'd like
Given A Pepr Module
When And environment variable named PEPR_STORE_DEBOUNCE_DELAY is set to 2000
Then The Pepr store uses 2000 for the internal debounce delay.
Describe alternatives you've considered
We could potentially expose two configuration values, one for the watch delay and one for the cache flush delay but I don't have strong feelings about that being the case.
Additional context
We are using Store.removeItemAndWait in our WIP finalizer which results in a long blocking delay before the resource is removed. I'm a bit on the fence if we should re-evaluate our own usage and switch to the non-blocking call but I think it is still something we'd like to configure regardless.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When interacting with the Pepr store and using functions like
Store.setItemAndWait
orStore.removeItemAndWait
the total time between function call and awaited return can be up to 10 seconds (5 seconds for flush, 5 seconds for watch) based on on the default debounce configuration for the store.Ideally this would be configurable to adjust based on the usage of the store.
Describe the solution you'd like
PEPR_STORE_DEBOUNCE_DELAY
is set to2000
2000
for the internal debounce delay.Describe alternatives you've considered
We could potentially expose two configuration values, one for the watch delay and one for the cache flush delay but I don't have strong feelings about that being the case.
Additional context
We are using
Store.removeItemAndWait
in our WIP finalizer which results in a long blocking delay before the resource is removed. I'm a bit on the fence if we should re-evaluate our own usage and switch to the non-blocking call but I think it is still something we'd like to configure regardless.The text was updated successfully, but these errors were encountered: