Skip to content

test(lark): date the manager-context fixtures from the run - #4798

Closed
DJC1412 wants to merge 1 commit into
loopx-project:mainfrom
DJC1412:codex/lark-context-retention-clock
Closed

DJC1412 wants to merge 1 commit into
loopx-project:mainfrom
DJC1412:codex/lark-context-retention-clock

Conversation

@DJC1412

@DJC1412 DJC1412 commented Sep 20, 2026

Copy link
Copy Markdown
Contributor

Goal And Delivered Outcome

  • Goal/source and gap: [Bug]: absolute fixture dates make the Lark manager-context tests expire after seven days #4797. Two manager-context tests in this file carried absolute 2026-09-13T05:59/06:00Z event dates while MANAGER_CONTEXT_MAX_AGE (loopx/extensions/lark/manager_context.py:28) drops material older than seven days measured against datetime.now(UTC). The fixtures therefore expired on 2026-09-20T05:59Z and have failed every branch since, including main itself.
  • Observable before → after, with the validation row that proves it: before, pytest -q tests/extensions/test_lark_goal_topic_runtime.py on a clean origin/main worktree gave 2 failed, 49 passed, both failures assert 0 == 1 on context_material_count; after, the same command gives 55 passed and keeps passing whenever it runs. Proven by the unit and regression_parity rows.
  • Issue/task and intended base: Closes [Bug]: absolute fixture dates make the Lark manager-context tests expire after seven days #4797. Base main.

Scope And Continuation

  • Completed scope and remaining work: one test-only helper, _fixture_time(minutes_ago), replaces the seven literals at 60/61 minutes ago, which preserves the ordering the tests rely on (context precedes the turn that consumes it) and resolves to whole minutes so the captured material and the expected dictionary still compare equal — the second symptom in [Bug]: absolute fixture dates make the Lark manager-context tests expire after seven days #4797 was exactly that mismatch reproducing with different microseconds. Not claimed: a direct test of the retention_expired branch. Reaching it through the shipped path means capturing material older than the collector's own seven-day lookback, so such a test would pass for a second reason and certify nothing; pinning the rule properly needs an injected now at the process_lark_goal_topic_event boundary, which is a production-signature decision rather than a fixture fix.
  • Slice boundary / successor: no production code, schema or clock source changes, so this is revertible on its own. The now-injection question stays with whoever owns the Lark manager adapter, noted in [Bug]: absolute fixture dates make the Lark manager-context tests expire after seven days #4797.

Validation

  • Tested revision: 9993fc511
  • Run state: finished
  • Input classes: public_fixture
Check kind Result Public-safe evidence / limitation
unit passed uv run --extra test python -m pytest -q tests/extensions/test_lark_goal_topic_runtime.py55 passed; the two previously failing tests are the ones that now pass.
integration passed uv run --extra test python -m pytest -q tests/extensions943 passed, no failures or skips introduced.
regression_parity passed Baseline is a clean origin/main worktree with this diff absent: 2 failed, 49 passed, with AssertionError: assert 0 == 1 at line 395/557 for the two named tests. Repository CI brackets the same expiry without any merge in between — run 35490703890 (main 361347713, 05:03Z) reports 0 failures in this file across all four shards, run 35494985951 (main 4eb6ea9ee, 06:43Z) reports both of them failing, either side of 2026-09-13T05:59Z + 7 days = 2026-09-20T05:59Z.
static passed python -m py_compile on the changed file; loopx check --scan-path tests/extensions/test_lark_goal_topic_runtime.py → public boundary scan clean.
  • Coverage and gaps: the change is confined to how one test module states event time, and the whole tests/extensions suite is the covering surface. Not run: npm run test:control-plane (no TypeScript touched), and the pre-existing tests/canary/test_maintainability_ratchet.py failure on main is unrelated to this diff — it also fails here for that reason alone, and I left the release-ceiling decision to its owner rather than widening a budget.

Frontend / Visual Evidence

  • UI impact: none — test-only change; Before/After/states are N/A and Source data is public_fixture.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Refactoring (no functional changes)
  • Documentation update
  • Test update

LoopX Area

  • Control plane (goals, todos, quota, scheduler, registry, runtime)
  • Benchmark boundary (adapters, runners, verifiers, scoring, evidence)
  • Capability or extension (providers, adapters, skills)
  • Public docs or presentation surface (README, protocols, dashboard)
  • Build, packaging, installer, or CI
  • Host or runtime integration

Technical Direction

  • Direction / acceptance reference, when applicable: suite reliability after the 1.1.0/organization migration window; no roadmap id.

Shared-authority RFC fixture impact

  • N/A: no production-scale fixture, provider conformance arm, promotion or routing change.

Boundary Checklist

  • Neither the diff nor this PR body/comments/attachments disclose private state, credentials, raw traces or verifier output, internal links, or local machine paths (including .loopx/, .codex/goals/, and live ACTIVE_GOAL_STATE.md).
  • I did not duplicate maintainer-owned benchmark work unless a maintainer split out a public issue for it.
  • I kept the change scoped to the linked issue/task.
  • I completed the visual evidence section for UI changes, or marked UI impact none.
  • Every commit includes a DCO Signed-off-by trailer (git commit -s).

Two manager-context tests carried 2026-09-13 timestamps while retention drops
material older than seven days measured against the wall clock, so both turned
red on their own seven days later and took every open pull request with them.
CI brackets the boundary: the 05:03Z main run passed this file, the 06:43Z main
run failed it, with no merge in between.

The helper resolves to whole minutes so the captured material and the expected
payload still compare equal, and the context keeps preceding the turn that
consumes it. Production code is untouched.

Signed-off-by: DJC1412 <108855841+DJC1412@users.noreply.github.com>

@huangruiteng huangruiteng left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Review of exact head 9993fc511fc6eb19b82b0d516a0e1813f5072afc

[P1] Anchor the relative clock once

_fixture_time() calls datetime.now(UTC) on every use, while both affected tests call it separately when constructing provider events and when constructing the expected context_materials. If execution crosses a whole-minute boundary between those calls, the same minutes_ago value resolves one minute apart and the equality assertion fails. That preserves a lower-frequency wall-clock flake in the test intended to remove the dated-fixture flake.

Please capture one whole-minute anchor once, either at module/test setup or in each affected test, and derive every related timestamp from that same anchor. A module-level _FIXTURE_NOW = datetime.now(UTC).replace(second=0, microsecond=0) is sufficient here because the material remains far inside the seven-day retention boundary.

Validation: the full test file passes locally (55 passed), which confirms the ordinary path; the blocker is the independently visible boundary transition between repeated clock reads. I found no production behavior, authority, privacy, or compatibility change in this test-only diff.

English verdict: REQUEST CHANGES - exact head 9993fc511fc6eb19b82b0d516a0e1813f5072afc; use one shared clock anchor so the regression test cannot fail at a minute boundary.

@huangruiteng

Copy link
Copy Markdown
Collaborator

Superseded by #4793, which merged the shared fixed-clock repair for the two dated manager-context fixtures together with the module-budget repair. The current main merge of #4802 includes that fix, and the three formerly failing post-merge checks now pass locally. Closing this alternate dynamic-time fixture approach so the repository keeps one canonical repair.

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.

[Bug]: absolute fixture dates make the Lark manager-context tests expire after seven days

2 participants