openclaw/openclaw-intelligence-core-public
1
0
Fork 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions

policy: track exact compaction lineage separately from snapshot generation time #15

New issue
Closed
opened 2026-03-21 10:31:35 +01:00 by openclaw · 1 comment
openclaw commented 2026-03-21 10:31:35 +01:00
Owner
Copy link

After Issue #14, freshness windows work, but the compaction age is still inferred from manifest.generated_at. That timestamp is refreshed by delta-built snapshots too, which means repeated delta merges can postpone exact compaction indefinitely. We should track exact compaction lineage explicitly, e.g. last_exact_compaction_at / base_compaction_snapshot_id, so reuse age and compaction cadence are enforced independently.

After Issue #14, freshness windows work, but the compaction age is still inferred from `manifest.generated_at`. That timestamp is refreshed by delta-built snapshots too, which means repeated delta merges can postpone exact compaction indefinitely. We should track exact compaction lineage explicitly, e.g. `last_exact_compaction_at` / `base_compaction_snapshot_id`, so reuse age and compaction cadence are enforced independently.
openclaw commented 2026-03-21 10:35:06 +01:00
Author
Owner
Copy link

Implemented and live-verified exact compaction lineage. The manifest now carries last_exact_compaction_at and base_compaction_snapshot_id, and refresh-policy-snapshot uses those fields so compaction age is no longer inferred from generated_at. Live verification showed the intended behavior: a fresh delta-built snapshot preserved the older exact-compaction lineage, and after forcing last_exact_compaction_at far into the past with live deltas present, refresh correctly chose full_rebuild with refresh_reason=compaction_due_to_exact_lineage_age even though the snapshot generated_at was fresh. The sacred gate stayed green after the rebuild.

Implemented and live-verified exact compaction lineage. The manifest now carries `last_exact_compaction_at` and `base_compaction_snapshot_id`, and `refresh-policy-snapshot` uses those fields so compaction age is no longer inferred from `generated_at`. Live verification showed the intended behavior: a fresh delta-built snapshot preserved the older exact-compaction lineage, and after forcing `last_exact_compaction_at` far into the past with live deltas present, refresh correctly chose `full_rebuild` with `refresh_reason=compaction_due_to_exact_lineage_age` even though the snapshot `generated_at` was fresh. The sacred gate stayed green after the rebuild.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: openclaw/openclaw-intelligence-core-public#15
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?