Repository navigation
test(cachekit): pin the write-behind receipt-delay excess behind a suspended wrapper (LAB-12540) - #311
Conversation
…nd a suspended wrapper A write-behind copy is in L1 before its PUT is sent and is capped only when the backend's set resolves, so a wrapper still suspended after the 2xx keeps it serving past receipt plus Fresh-For, never past its TTL from the L1 fill. The protocol now names this the receipt-delay excess; the README and the SetResult doc say so.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 28 minutes. View limit details
Tip 🎯 Customize your risk assessments
✅ Automatic approvals, with your rules
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. CodeRabbit Verify
|
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
![kodus-27b[bot]](https://avatars.githubusercontent.com/u/223823690?s=60&v=4){kind=small}
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…cite API-103 Review follow-up: the ceiling test now shows a hit just before fill plus ttl and a miss at it, with Fresh-For 0, so it fails if L1 was never filled. The protocol states the receipt-delay excess under API-103, not a new id.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
Review follow-up: the Fresh-For 0 test pins the TTL-from-fill ceiling, since the header never reaches CacheImpl while the wrapper is suspended; drop an assertion that restated the clock advance; cite API-103 once in SetResult.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
Instruction counts: PASSHead All 36 workloads: 36 ok
|
|
@kody start-review |
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
What
This PR adds tests that pin how a
writeBehindL1 copy behaves while a custom backend wrapper is still suspended after the innersetresolved. It also aligns the README and theSetResultdoc with the protocol's new wording, the receipt-delay excess under API-103 (cachekit-io/protocol#231).The new tests are in
src/backends/cachekitio-freshness.test.ts, underbehind a wrapper still suspended after the PUT 2xx:Fresh-For: 1, wrapper suspended past 1 s after receipt. Aget()is still served from L1. Once the wrapper resolves, the copy is capped at receipt + 1 s.Fresh-For: 0,ttl: 2, wrapper still suspended. The copy is served at fill + 1.999 s and expires at fill + 2 s. That expiry is the excess's ceiling. The existing write-behindFresh-For: 0test covers the drop once the wrapper resolves.There is no runtime change. CacheImpl already caps the copy when
setresolves, which is what the protocol requires.Why
A write-behind copy is in L1 before the
PUTis sent. CacheImpl learnsSetResult.receivedAtonly when the backend'ssetresolves, so a wrapper that keeps working after the innersetdelays the cap. The earlier tests advanced the clock inside the wrapper, so they never read while it was suspended. These tests do.Checks
pnpm run lint,pnpm run type-check:testsand Prettier on the changed files all pass.vitest runpasses afterpnpm build.