Skip to content
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

Use a consistent timebase when evaluating soft/hard TTLs. #391

Merged
merged 1 commit into from
Jan 26, 2021

Conversation

jpd236
Copy link
Collaborator

@jpd236 jpd236 commented Jan 25, 2021

Previously, we'd evaluate whether a cache entry was valid per these TTLs using two different checks against the current system time. This could result in a spurious trigger of soft TTL logic if the first time check occurs before the soft TTL expiry but the second occurs after it, and the hard and soft TTL are identical.

Unit tests are omitted since we don't have an easy way to mock the clock with the current architecture. This could be improved in the future.

Fixes #388

Previously, we'd evaluate whether a cache entry was valid per these TTLs using two different checks against the current system time. This could result in a spurious trigger of soft TTL logic if the first time check occurs before the soft TTL expiry but the second occurs after it, and the hard and soft TTL are identical.

Unit tests are omitted since we don't have an easy way to mock the clock with the current architecture. This could be improved in the future.
@jpd236
Copy link
Collaborator Author

jpd236 commented Jan 26, 2021

PR reviewed offline by @uhager - going ahead and merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant