freemo
8ea00f5185
CI / unit_tests (push) Has been cancelled
CI / benchmark-publish (push) Has been cancelled
CI / lint (push) Has been cancelled
CI / typecheck (push) Has been cancelled
CI / security (push) Has been cancelled
CI / quality (push) Has been cancelled
CI / integration_tests (push) Has been cancelled
CI / e2e_tests (push) Has been cancelled
CI / coverage (push) Has been cancelled
CI / benchmark-regression (push) Has been cancelled
CI / build (push) Has been cancelled
CI / push-validation (push) Has been cancelled
CI / status-check (push) Has been cancelled
CI / docker (push) Has been cancelled
CI / helm (push) Has been cancelled
Co-authored-by: Jeffrey Phillips Freeman <the@jeffreyfreeman.me> Co-committed-by: Jeffrey Phillips Freeman <the@jeffreyfreeman.me>
43 lines
2.0 KiB
Gherkin
43 lines
2.0 KiB
Gherkin
# @tdd_issue @tdd_issue_821 @mock_only @tdd_expected_fail @tdd_issue_4178 @skip
|
|
@skip
|
|
Feature: TDD Issue #821 — context tier service has data models but no runtime logic
|
|
As a developer
|
|
I want to verify that ContextTierService automatically promotes, demotes,
|
|
and evicts fragments based on access patterns, staleness, and budget limits
|
|
So that the bug is captured and will be caught by a regression test
|
|
|
|
Bug #821 identified that ContextTierService had data models for
|
|
hot/warm/cold tiers (ContextTier, TieredFragment, TierBudget) and
|
|
manual promote()/demote()/evict_lru() methods, but NO automatic
|
|
runtime logic. The bug has been fixed — ContextTierService now:
|
|
|
|
- auto-promotes frequently accessed cold/warm fragments to a higher tier,
|
|
- enforces staleness by demoting stale hot fragments to warm/cold,
|
|
- enforces budget limits by evicting on hot tier overflow.
|
|
|
|
These tests serve as a permanent regression guard for the fix.
|
|
|
|
# @tdd_issue @tdd_issue_4278 @tdd_expected_fail @skip
|
|
@skip
|
|
Scenario: Promotion on repeated access moves fragment to a higher tier
|
|
Given a context tier service with default budget
|
|
And a fragment stored in the cold tier
|
|
When I access the fragment 5 times via get
|
|
Then the fragment should have been promoted to warm or hot tier
|
|
|
|
# @tdd_issue @tdd_issue_4278 @tdd_expected_fail @skip
|
|
@skip
|
|
Scenario: Demotion on staleness moves fragment to a lower tier
|
|
Given a context tier service with default budget
|
|
And a fragment stored in the hot tier with a stale last_accessed timestamp
|
|
When I invoke the staleness enforcement runtime
|
|
Then the fragment should have been demoted to warm or cold tier
|
|
|
|
# @tdd_issue @tdd_issue_4278 @tdd_expected_fail @skip
|
|
@skip
|
|
Scenario: Eviction on hot tier budget overflow removes oldest fragment
|
|
Given a context tier service with a small hot tier budget of 100 tokens
|
|
And the hot tier is filled to its token budget limit
|
|
When I store one more fragment in the hot tier
|
|
Then the oldest fragment should have been evicted from the hot tier
|