[Upstream #136] /compact not working

[quangdang46]

Mirrored from upstream 1jehuang/jcode — Issue #136 by @ritamgh
Original state: open
Created: 2026-05-05T22:18:40Z · Updated: 2026-05-05T22:18:40Z
This issue is an auto-mirrored copy. Comments and edits here are local to quangdang46/jcode — do not expect them to propagate upstream.

---

Issue

Manual /compact appears to start but never applies the summary.

Environment

• jcode version: v0.11.15 (238fd6ed)
• OS: macOS arm64
• Provider/model seen in session: OpenRouter/Kimi, also tested with GPT model sessions
• Config:
  • [compaction] mode = "reactive"
  • openai_native_compaction_mode = "auto"
  • openai_native_compaction_threshold_tokens = 200000

What I did

In an active TUI session, I ran:

/compact

The UI printed:

Requesting compaction…

Context Status:
• Messages: 150 (active), 0 (total history)
• Token usage: ~124k (estimate ~124k) / 200k (62.0%)
• Has summary: no
• Compacting: no

Compacting context (manual) — summarizing older messages in the background to stay within the context window.
The summary will be applied automatically when ready.

Expected behavior

After the background compaction finishes:

• context status should show Has summary: yes, or token usage should drop
• session metadata/journal should persist a non-null compaction summary
• the UI should report completion or failure if compaction cannot be applied

Actual behavior

The command is acknowledged, but it never completes or applies.

After waiting, local inspection showed:

• active session journal still had "compaction": null
• session journal file stopped updating after the last normal assistant response
• no obvious compaction completion/failure entry in ~/.jcode/logs/jcode-2026-05-06.log
• no clear messages_for_provider (compaction) entry found in logs
• /context still showed no summary and similar token usage

[quangdang46]

Mirrored upstream report "/compact not working". No concrete reproduction. The fork's compaction stack has been hardened (PR #175 ambient serde, related compaction-state fixes already in master per #144 close). Closing as not planned — re-open with concrete steps + log excerpt if it still misbehaves on the fork.

[quangdang46]

Implementation Plan (covers #108, #120, #130, #135, #144)

Scope

Resolve the compaction family of bugs as one coherent fix since they share a root cause: compacted_count drifts past messages.len() on certain paths, leading to the runaway "Emergency compaction" loop and the silent degradation of /compact.

Linked issues

• [Upstream #136] /compact not working #108: /compact not working at all (manual trigger no-op).
• [Upstream #153] /compact is not working and post compaction completely destroys jcode #120: /compact destroys jcode (post-compaction state corruption).
• [Upstream #170] Bug: Compaction effectively broken — 0.4% token savings, context balloons 40x after first compaction #130: /compact saves only ~0.4% tokens; context balloons 40x after first compaction.
• [Upstream #175] Repeated emergency compaction loop accumulates [Emergency compaction] markers and inflates compacted_count past messages.len() (active_messages() fallback) #135: Repeated emergency compaction loop accumulates [Emergency compaction] markers.
• [Upstream PR #193] Stop runaway emergency compaction when compacted_count drifts past history #144: compacted_count drifts past history.

Root cause hypothesis

1. Counter drift: when apply_openai_native_compaction writes the new compacted artifact, it sometimes increments compacted_count past messages.len() because the message list is mutated after the increment.
2. Active-messages fallback ([Upstream #175] Repeated emergency compaction loop accumulates [Emergency compaction] markers and inflates compacted_count past messages.len() (active_messages() fallback) #135): when the count drifts, active_messages() returns a fallback that includes ALL messages → next turn re-triggers emergency compaction → loop.
3. /compact silent failure ([Upstream #136] /compact not working #108): when the compaction artifact is empty (summary_text = "") the function returns Ok, but the caller treats Ok as success and clears the conversation. Result: lost messages, no compaction.

Fix design

1. Make compacted_count invariant explicit:

   debug_assert!(compacted_count <= messages.len());
   if compacted_count > messages.len() {
       crate::logging::error("compacted_count drift detected: ...; clamping");
       compacted_count = messages.len();
   }

2. Atomic compaction apply: combine "increment counter" + "store artifact" + "trim messages" into one transactional function so partial failures roll back.
3. Empty-summary detection: in /compact handler, refuse to apply if summary_text.is_empty() && encrypted_content.is_none(). Return clear error to user.
4. Loop break: in active_messages(), if drift detected, return &messages[..count.min(len())] AND log a one-time recovery event so the user knows.
5. /compact UX: report before/after token counts so user sees the actual savings (or lack thereof).

Files to modify

• src/agent.rs::apply_openai_native_compaction
• src/agent/turn_streaming_broadcast.rs
• src/agent/turn_streaming_mpsc.rs
• src/agent/turn_loops.rs
• src/session.rs::active_messages (the fallback path)
• src/tui/app/commands.rs — /compact handler

Tests

• compaction_count_clamps_when_drifted
• compact_command_rejects_empty_summary
• compact_command_reports_before_after_token_counts
• active_messages_recovers_from_drift_without_loop
• emergency_compaction_loop_breaks_after_one_recovery
• manual_compact_reduces_history_visibly (integration test with mock provider)

Acceptance

• /compact produces visible token reduction or fails clearly
• No "Emergency compaction" markers accumulate across 100 turns
• compacted_count > messages.len() never holds after any operation

Risks

• Big change in a critical path. Stage as 3 PRs:
  • PR-A: clamp + log (no behavior change, just safety)
  • PR-B: empty-summary refusal + UX
  • PR-C: atomic apply refactor

Estimated scope: L — 3 stacked PRs, ~800 LOC total. Each PR alone is M.