Hygiene Agent In-Place Compression Fails: _last_compaction_in_place Not Set

[Xwm1234]

Hygiene Agent In-Place Compression Fails: _last_compaction_in_place Not Set

Problem Description

Gateway hygiene compression reports "no session_db on the hygiene agent" warning even though:

1. compression.in_place = true is configured
2. Session DB is correctly passed to the hygiene agent
3. Compression executes successfully

Symptoms

[PRATHAMESH75]

Thanks for the report. I traced the flag through the gateway hygiene path and can't reconcile the described state from the body alone — a couple of specifics would let a fix target the real branch rather than guess.

Where the flag is set. agent._last_compaction_in_place is assigned from compacted_in_place at agent/conversation_compression.py:1751, and compacted_in_place only flips to True at line 1508 — inside if agent._session_db: (1469) → if in_place: (1478), immediately after archive_and_compact() succeeds.

Where the DB comes from. The gateway hygiene agent is built with session_db=_hyg_session_db (gateway/run.py:~12816), which agent_init.py:1471 stores as agent._session_db, and the same block sets compression_in_place = True. So on a successful in-place compaction the flag should already be True, and the no session_db on the hygiene agent warning (gateway/run.py:12924) fires only in the terminal else branch — i.e. when neither rotation nor in-place archive completed.

That points at the persist try block (conversation_compression.py:1471–1508) raising and being swallowed at its except (~1638), which leaves compacted_in_place=False even though a summary was produced — which reads as "compression executed successfully" but the flag never set. To pin down which branch actually drops it:

1. Is the gateway itself DB-backed at that moment? _hyg_session_db = getattr(self._session_db, \"_db\", self._session_db) yields None when the gateway has no _session_db, and agent._session_db=None reproduces exactly these symptoms while still "passing" a value to the constructor.
2. The failing log line — any error logged from archive_and_compact() or the compression except block, plus the resulting split_status.
3. Your compression.* config block, and confirmation this is the gateway-hygiene path above (vs the /compress command, which has its own binding at gateway/slash_commands.py:3576).

With the failing log line + config I can identify which branch drops the flag and put up a targeted fix with a regression test.

[Xwm1234]

Supplementary Information — Issue #71097

1. Key Finding: Compression Works, But Gateway Reports False Warning
   At the same timestamp (2026-07-25 16:36:20), agent-level shows compression succeeded, but gateway-level reports "no session_db" warning.
   Agent Level (Success)
   plaintext

2026-07-25 16:36:20 INFO agent.conversation_compression:
context compression attempt telemetry: {
"split_status":"in_place_committed",
"commit_status":"committed",
"total_duration_ms":1933
}
Gateway Level (Warning)
plaintext

2026-07-25 16:36:20 WARNING gateway.run:
Gateway hygiene compression for session 20260724_154103_b0cd09
did not rotate or compact in place
(no session_db on the hygiene agent) —
preserving the original transcript instead of overwriting it with the summary (#21301).
2. Full Compression Configuration
yaml

compression:
enabled: true
threshold: 0.5
target_ratio: 0.4
protect_last_n: 50
hygiene_hard_message_limit: 200
protect_first_n: 3
abort_on_summary_failure: false
codex_gpt55_autoraise: true
in_place: true
3. Another Issue: Some Compression Aborted
plaintext

2026-07-25 12:36:50 INFO agent.conversation_compression:
context compression attempt telemetry: {
"split_status":"aborted",
"commit_status":"aborted",
"failure_class":"no_progress",
"current_estimated_tokens":101068,
"protected_tail_tokens":372137
}
protected_tail_tokens (372K) > current_estimated_tokens (101K), causing compression to abort.
4. Possible Root Causes
Timing issue: Gateway checks _last_compaction_in_place before agent sets the flag
Check logic issue: Gateway's check condition may be incorrect
Abort case: When compression is aborted, gateway should not report "no session_db" warning
5. Suggestions
Check the timing of _last_compaction_in_place check in gateway.run
Distinguish between "compression failed" and "compression aborted" scenarios
When split_status: "in_place_committed", should not report "no session_db" warning
6. Environment
Hermes version: Latest (commit 477c08b)
Python: 3.11
OS: macOS (Apple Silicon)
Issue persists after gateway restart