Ensure invalidate doesn't mutate response x-status key #25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When invalidate is called the method to restore response mutates the x-status key in the header hash. Previously, in the case where one entry is fresh and others are not, the not- fresh entries could be persisted without any x-status header, potentially later serving requests with status code 0. This change removes that possibility by always using the rehydrated response when mapping over entries to invalidate.
|
I ran the failing test locally to confirm the issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I ran into an issue where our application was serving responses with HTTP status code 0. I noticed that some of our metastore cache entries didn't have an
x-statuskey.I found that this occurs on
invalidatewhen at least one entry is fresh. In this case all stale entries are written back to the cache withoutx-status.It seem that the method to restore responses mutates the x-status key in the header hash (resp), and then the same, modified object is written back to the cache.
rack-cache/lib/rack/cache/meta_store.rb
Line 147 in 0ffee48
This change removes that possibility by always using the rehydrated response when mapping over the entries to invalidate.
This surfaced in my app during the upgrade to Rails 6.1, but I haven't figured out that part of the equation yet.