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
Currently, if guards are loaded from a config, their history is held in memory. We already have an endpoint for fetching history for a specific guard call that we use when communicating between the client and the server. This cache applies a 5 minute TTL on each history entry as well as limits the cache to only 50 entries to prevent memory leaks.
However, since the guards are now objects kept in memory in the config rather than constructed JIT from the database, history is still being held on the guard instances. We should delete/reset Guard.history to an empty Stack once a /validate call is done. We should also investigate other means of dumping/persisting history somewhere else via a logging API.
The text was updated successfully, but these errors were encountered:
Currently, if guards are loaded from a config, their history is held in memory. We already have an endpoint for fetching history for a specific guard call that we use when communicating between the client and the server. This cache applies a 5 minute TTL on each history entry as well as limits the cache to only 50 entries to prevent memory leaks.
However, since the guards are now objects kept in memory in the config rather than constructed JIT from the database, history is still being held on the guard instances. We should delete/reset Guard.history to an empty Stack once a
/validate
call is done. We should also investigate other means of dumping/persisting history somewhere else via a logging API.The text was updated successfully, but these errors were encountered: