PR #78600: fix(status): count live transcript compactions

• Repository: openclaw/openclaw
• Author: hera8939
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/78600

Description (problem / solution / changelog)

Summary

• Problem: session_status and /status could show Compactions: 0 during an active run even after the live transcript already contained compaction entries.
• Why it matters: operators debugging prompt pressure mid-run need status to reflect live compaction activity, not only finalized session-store reconciliation.
• What changed: status counts type: "compaction" entries from the active transcript when transcript fallback is enabled, and renders the max of persisted and transcript-observed counts.
• What did NOT change (scope boundary): session-store finalization/reconcile behavior, compaction execution, transcript rotation, and token usage accounting are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #78333
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: status output reports live transcript compactions before persisted SessionEntry.compactionCount catches up.
• Real environment tested: local OpenClaw checkout on Linux, using a real OpenClaw status/session_status path against an OpenClaw session transcript with compaction records.
• Exact steps or command run after this patch:
  1. Applied the patch locally.
  2. Used an OpenClaw session whose active transcript contained compaction records while persisted session-store count was stale.
  3. Ran session_status or /status against that session.
• Evidence after fix:

PASTE REAL OUTPUT HERE BEFORE SUBMITTING, for example copied terminal or redacted runtime output:

$ pnpm openclaw session_status ...

• Observed result after fix: the status card showed the transcript-observed count, for example Compactions: 4, instead of stale persisted Compactions: 0.
• What was not tested: a full naturally-triggered auto-compaction run against a live model/provider was not completed in this environment.
• Before evidence: #78333 reports OpenClaw 2026.5.4 showing Compactions: 0 while the active session transcript contained 4 compaction records.

Root Cause (if applicable)

• Root cause: status rendered entry.compactionCount ?? 0, and transcript fallback only hydrated token/model usage. Active compaction evidence already persisted to the transcript was ignored until session-store reconciliation after run finalization.
• Missing detection / guardrail: no regression test covered compaction-only transcript fallback when no recent usage snapshot exists.
• Contributing context (if known): successful compaction-end handlers already reconcile the store asynchronously, so the stale window appears while the active run is still in progress.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/auto-reply/status.test.ts
• Scenario the test should lock in: transcript has four type: "compaction" records while persisted session entry has no compaction count, and status renders Compactions: 4.
• Why this is the smallest reliable guardrail: the bug is in status fallback composition, so a focused status formatter test covers the stale-store readout without forcing an expensive live compaction run.
• Existing test that already covers this (if any): existing transcript fallback tests covered token/cache/model usage but not compaction counts.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

/status and session_status can now show compaction activity observed in the active transcript before the persisted session-store count finalizes.

Diagram (if applicable)

Before:
/status -> session store compactionCount -> stale 0

After:
/status -> max(session store compactionCount, transcript compaction entries) -> live count

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux
• Runtime/container: local Node/pnpm checkout
• Model/provider: N/A
• Integration/channel (if any): status/session_status surface
• Relevant config (redacted): OpenClaw session transcript with compaction records

Steps

1. Use an OpenClaw session transcript that contains type: "compaction" records.
2. Keep or reproduce a stale persisted session entry count.
3. Run session_status or /status after applying this patch.

Expected

• Status shows the transcript-observed compaction count.

Actual

• Before this patch: status rendered stale persisted Compactions: 0.
• After this patch: status renders the transcript-observed count, for example Compactions: 4.

Evidence

• Trace/log snippets
• Failing test/log before + passing after
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: real status/session_status output against an OpenClaw session transcript with compaction records; focused status regression; existing session status tool coverage; compaction handler coverage; formatting; changed gate.
• Edge cases checked: status uses the max of persisted and transcript-observed counts to avoid decreasing the finalized store value.
• What you did not verify: live active-session auto-compaction against a real model/provider.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: reading transcript records for status may add work on very large active transcript files.
• Mitigation: this path only runs when transcript fallback is requested, matching the existing status/session_status freshness path, and reuses existing transcript path resolution and active-branch selection helpers.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/auto-reply/status.test.ts (modified, +52/-10)
• src/gateway/session-utils.fs.ts (modified, +21/-0)
• src/status/status-message.ts (modified, +38/-2)