brent.edwards
f324575a3b
CI / lint (push) Has been cancelled
CI / security (push) Has been cancelled
CI / typecheck (push) Has been cancelled
CI / benchmark-publish (push) Has been cancelled
CI / build (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 / status-check (push) Has been cancelled
CI / unit_tests (push) Has been cancelled
CI / docker (push) Has been cancelled
CI / helm (push) Has been cancelled
The @tdd_expected_fail tag was already absent from the tag lines of both features/tdd_context_tier_runtime.feature (bug #821) and features/tdd_plan_apply_yes_flag.feature (bug #932). However, the feature description and step-definition docstring for bug #821 still referenced the @tdd_expected_fail tag and described the bug as unfixed. Updated the feature description in tdd_context_tier_runtime.feature and the module docstring in tdd_context_tier_runtime_steps.py to reflect that bug #821 has been fixed and these tests now serve as permanent regression guards. No changes were needed for bug #932 as its files had no stale references. Permanent tags @tdd_issue / @tdd_issue_821 and @tdd_issue / @tdd_issue_932 remain in place per the CONTRIBUTING.md TDD Issue Test Tags convention. ISSUES CLOSED: #1206 Co-authored-by: Brent E. Edwards <brent.edwards@cleverthis.com> Co-committed-by: Brent E. Edwards <brent.edwards@cleverthis.com>
36 lines
1.8 KiB
Gherkin
36 lines
1.8 KiB
Gherkin
@tdd_issue @tdd_issue_821 @mock_only
|
|
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.
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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
|