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.

Sign up for GitHub

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

Jump to bottom

re-introduce cache healing when we see an invalid cache entry #1707

Merged
merged 3 commits into from
Feb 19, 2024
Merged

re-introduce cache healing when we see an invalid cache entry #1707

merged 3 commits into from
Feb 19, 2024

Commits on Feb 19, 2024

  1. uv-client: move response handling to its own function 

    This is just moving code to make it easier to use response handling in a
different context. No behavior changes.
    @BurntSushi
    BurntSushi committed Feb 19, 2024
    Configuration menu
    Copy the full SHA
    be0d110 View commit details
    Browse the repository at this point in the history

  2. uv-client: tweak 'fresh_request' to be more flexible 

    Basically, instead of it wrapping its data up inside an enum, we just
return the data itself. That way, the caller can control what is done
with it. Right now, all uses just wrap it into the enum anyway, so this
looks somewhat pointless, but we'll use this flexibility in the next
commit.
    @BurntSushi
    BurntSushi committed Feb 19, 2024
    Configuration menu
    Copy the full SHA
    a0b7552 View commit details
    Browse the repository at this point in the history

  3. uv-client: make the cache heal itself 

    This change detects payload deserialization errors, emits a (non-user)
warning and sends a fresh request to get new data.

This self-healing existed before some of my zero-copy deserialization
work landed, but my changes ended up losing half of it. The half that
still remains is if the cache policy itself fails to deserialize (since
it is done separately from the payload). This commit now also does it if
the payload fails to deserialize.

Unfortunately, we do clone the request here pessimistically in case we
need to resend it. Indeed, we might end up sending two requests: a
re-validation request and then another fresh request if we discover our
cached data is bad after the revalidation request.

We could try to deserialize the cached data before (possibly) sending
the initial request. But this does extra work (checking the validity of
the cached copy) even if we don't use it. It's hard to know exactly
which approach would be faster, but I went this route because the
request is typically very small.
    @BurntSushi
    BurntSushi committed Feb 19, 2024
    Configuration menu
    Copy the full SHA
    5407034 View commit details
    Browse the repository at this point in the history