feat(cache): precompute weak ETag per cache entry#351
Conversation
Store a weak ETag opaque tag on CacheItem::Found, computed once when the
rendered (config-templated) bytes are cached. Consumers can serve it as
`W/"{etag}"` and answer conditional requests without re-hashing the body
on every request — the DuckDB WASM assets are 30-40 MB.
Use xxh3 (as the catalog already does for loadTable ETags) instead of the
std DefaultHasher: ~4x faster on the WASM blobs and, unlike SipHash, a
fixed algorithm — so the tag stays stable across Rust releases and won't
spuriously invalidate caches on a toolchain bump.
WalkthroughThe cache adds weak ETags to found entries, computes them from rendered bytes using xxh3, and validates stability for identical content and changes caused by forwarded prefixes. ChangesWeak ETag caching
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
console-rs/src/cache.rs (1)
36-39: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider padding the hex string to a consistent length.
While ETags are opaque and variable lengths are perfectly valid, using
{:016x}ensures that the generated tag always has a uniform 16-character width, even if the resulting hash contains leading zeros.♻️ Proposed refactor
fn weak_etag_tag(data: &[u8]) -> String { - format!("{:x}", xxhash_rust::xxh3::xxh3_64(data)) + format!("{:016x}", xxhash_rust::xxh3::xxh3_64(data)) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@console-rs/src/cache.rs` around lines 36 - 39, Update weak_etag_tag to format the xxh3_64 hash as a zero-padded 16-character lowercase hexadecimal string using the existing hash value, ensuring every generated ETag has consistent width.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@console-rs/src/cache.rs`:
- Around line 36-39: Update weak_etag_tag to format the xxh3_64 hash as a
zero-padded 16-character lowercase hexadecimal string using the existing hash
value, ensuring every generated ETag has consistent width.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 24bff53c-4279-46fe-a0c9-17096206f6f9
📒 Files selected for processing (2)
console-rs/Cargo.tomlconsole-rs/src/cache.rs
1 participant
Store a weak ETag opaque tag on CacheItem::Found, computed once when the rendered (config-templated) bytes are cached. Consumers can serve it as
W/"{etag}"and answer conditional requests without re-hashing the body on every request — the DuckDB WASM assets are 30-40 MB.Use xxh3 (as the catalog already does for loadTable ETags) instead of the std DefaultHasher: ~4x faster on the WASM blobs and, unlike SipHash, a fixed algorithm — so the tag stays stable across Rust releases and won't spuriously invalidate caches on a toolchain bump.
Summary by CodeRabbit
New Features
Bug Fixes