Fix bug where data would sometimes not get loaded into cache after successful read #1524
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.
This bug had no impact on correctness, but could impact performance by preventing blocks for series that weren't already in memory from being added to the cache after being read from disk.
Bug was introduced by #1421
Basically even when there are no encoded tags, we wrapped the bytes into a checked.Bytes. The retriever would see that the encoded tags weren't nil and try to put them into a tag decoder. The tag decoder would attempt to read nil bytes and return an error which would prevent a new shard entry from being created for items that were recently read and needed to be put in the cache.
This P.R fixes the issue by performing a length test in the retriever so even if it receives checked.Bytes with zero length it will ignore it AND it changes the seek logic to only pass along a non-nil checked.Bytes if the encoded tags have length larger than zero.
It also adds a regression to test to the retriever to prevent this from happening in the future.