Skip to content

Conversation

@maxstack
Copy link
Collaborator

Fixes for the chunk cache:

  1. Request offset and size not included in the cache key so the different byte ranges received by these requests would be cached in the same file causing errors in results
  2. Fix thread issue where tasks processing requests could access the cache state whilst being written via get_metadata
  3. Take unnecessary request parameters out of the key so the cache may hit more, we only include the source, bucket, object key, offset, and size - these are the parameters used by S3 object download API calls

…nloaded byte range under a key that doesn't account for this range.

When another request is received we get a cache hit even though the requested byte range may differ.

Fix this by downloading and caching the entire chunk, applying the byte range post download or cache hit.

If caching is disabled honour the byte range in the S3 client download.
…ache chunks aren't shared between requests of differing byte range.

Revert the previous fix which suffers from memory over consumption when bombarded by requests for byte ranges from the same very large file - we would need a way to ensure a single download of that file before servicing concurrent requests against it.
 1) Only incorporate request fields that themselves are used in the S3 object download
 2) Immediately turn this key into a md5 hash so we're handling a much shorter string when interacting with the cache
…essing task to determine if a chunk is cached and if so its size.

There's a MPSC channel used to buffer all cache write requests to a single task responsible for cache updates but the update task could happen at the same time request processing tasks read the state.
Reading the state file whilst it's being written results in a serde parsing error.

Instead of adding some type of thread safety around the load/save of the state file a simpler solution is to store a chunk's metadata in its own metadata file.
This mirrors the chunk get which ignores the state file and simply retrieves files from disk.
@maxstack maxstack self-assigned this Apr 17, 2025
Copy link
Contributor

@sd109 sd109 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, seems like a sensible approach to me.

Do we also need to be worried about the pruning cycle trying to access the cache state file while the cache is being written to? I see we're using load_state in the remove method as well as in various places throughout the prune* methods.

@maxstack maxstack force-pushed the fix/chunk-cache-offset-and-size branch from 2638d03 to eed4a06 Compare January 13, 2026 18:03
@maxstack maxstack force-pushed the fix/chunk-cache-offset-and-size branch from eed4a06 to 64a4e24 Compare January 14, 2026 10:32
…chunks independently, two users requesting the same chunk will cache it independently with no sharing involved - this is the fastest way to enable authentication by default
@maxstack maxstack marked this pull request as ready for review January 14, 2026 13:48
@maxstack maxstack merged commit 3be550b into main Jan 14, 2026
8 checks passed
@maxstack maxstack deleted the fix/chunk-cache-offset-and-size branch January 14, 2026 13:54
@maxstack maxstack changed the title Draft Fix chunk cache key and metadata retrieval Fix chunk cache key and metadata retrieval Jan 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants