Detect body format after reading from cache and restore content-type header #3759
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.
What this PR does:
This fixes a bug introduced in #3731 and caching the new protobuf responses. Cache loses the Content-Type header and therefore it falls back to json parsing which fails with an error like
error unmarshalling response body: invalid character '\x17' looking for beginning of value
. This is a quick work-around to readd the Content-Type by detecting the format. I wish we could use https://pkg.go.dev/net/http#DetectContentType but it doesn't seem to detect either json or proto, and yields eithertext/plain
orapplication/octet-stream
.Long-term cache needs to be updated to store the http response more comprehensively, likely including all headers. And add more structure around upgrading/migration cache content. Changing the cache key (
stv:v1
->stv:v2
) isn't sufficient in this case because the cache key is determined by the frontend, and the response format by the querier, so there is a disconnect.Which issue(s) this PR fixes:
Fixes #
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]