Bug: compactor rejects valid short summaries with “summary is not smaller”

[seicka]

Summary

The session compactor aborts when the generated summary is longer than the shadowed content, even for a very short turn. The whole agent turn is terminated instead of retaining the original content or skipping compaction.

Reproduction

• DeepSeek Harness: @deepseek-ai/dsh 0.1.1-rc.2
• OS: Windows 11 x64
• Profile: headless
• Provider: OpenAI-compatible Ollama adapter
• Model: Qwen3.8-9B uncensored GGUF (local)
• Workspace: Windows path

Run a short tool-using task that triggers compaction, for example:

Create a small file, execute it, and report the result. Use tools explicitly.

After the tool calls, compaction ends with:

summary is not smaller than the shadowed content (254 estimated framed tokens >= 67)

A second occurrence in the same test session was:

summary is not smaller than the shadowed content (554 estimated framed tokens >= 67)

The JSONL event is:

{"type":"compaction/end","data":{"error":"summary is not smaller than the shadowed content (254 estimated framed tokens >= 67)"}}

Expected behavior

If the summary is not smaller, compaction should be skipped and the shadowed content retained, or the summary should be replaced with a minimal marker. It should not abort the agent turn.

Actual behavior

The compaction step reports an error and the session terminates prematurely after otherwise successful tool calls.

Notes

This is especially likely with short Windows tool-call turns, where framing overhead makes a summary larger than the content being replaced. A simple fallback such as if summary_tokens >= shadowed_tokens: return no_compaction appears sufficient.

[argszero]

Verified against rc.2 (HEAD b150a55) — your repro is line-exact, but the "terminates the session" attribution needs a correction: this error does not abort the turn. The guard is real, deliberate, and tested; its blast radius is smaller than the report suggests.

1. The guard is intentional, with a regression test
packages/compaction/compaction-basic/src/region.ts:374-378 (summarizeCompaction):

if (framedSummaryTokenCount >= prepared.shadowedTokenCount) {
  throw new Error(`summary is not smaller than the shadowed content (...)`)
}

and compaction-basic.spec.ts:1073-1078 asserts rejects.toThrow(/summary is not smaller/). Design intent: never commit a checkpoint that makes the context grow — your own numbers (254 framed >= 67 shadowed) are exactly the guard working. Replacing 67 tokens with a 254-token framed checkpoint would be counterproductive, and the durable content is retained correctly (the replacement commitCompactionBody is never reached; the original nodes stay).

2. The turn does not terminate — both automatic triggers catch it

• Pressure path (agent/pre-step hook, compaction-basic/src/index.ts:147-165): compactIfNeeded is wrapped in try/catch; on failure it logs step compaction failed: ...; continuing the turn and returns next(). The turn continues.
• Context-overflow path (agent/request-error hook, index.ts:179-223): also try/catch; on failure without durable surface progress it logs and returns next() (preserving the original request error); with progress it returns { kind: 'retry' }.
• Headless exit: packages/bundle/headless/src/index.ts:133 io.exit(outcome.reason?.kind === 'completed' ? 0 : 1) — the exit code depends only on the turn/end reason, never on a compaction/end event carrying an error field. The bracket closes (with error), so there is no dangling compaction/start — nothing for replay repair to trip on.

Can you confirm what turn/end reason your session recorded? If it is completed, the session ended normally and the compaction failure is a red herring for termination; if error, the terminating error is a different event (the JSONL tail would show it).

3. The real cost is different: repeated wasted summarizer calls + warn spam
While pressure persists, every pre-step re-qualifies the same tiny range and re-runs the summarizer (a real LLM call through summarizeWithLlm), then throws and logs step compaction failed — with no dedup for this error class (only TargetPressureConfigError gets a warnedPressureConfigTargets dedup, index.ts:155-159). So a short turn under persistent pressure burns one summarizer call per step. That is the actual operational damage, not the (non-)termination.

4. Fix placement (endorses your fallback, sharpened)

• The guard should be a soft-skip, not a throw, for the automatic paths: return a typed no-op / null from compactIfNeeded when the framed summary would not shrink, so the caller treats it as "nothing useful to compact" instead of a failure. Your if summary_tokens >= shadowed_tokens: return no_compaction is exactly this.
• Keep the manual /compact path surfacing it (a user asking to compact a 67-token turn deserves an informative message, not silence) — so make it a typed result the manual command renders as guidance ("this range is too small to compact profitably") rather than a raw thrown string.
• Avoid the wasted LLM call entirely: add a minimum-shadowed-size pre-check before invoking the summarizer. For any range whose shadowed token count is below a small floor, the framed summary cannot shrink it (framing alone costs more), so skip summarization without calling the model. This is the higher-value half of the fix — it eliminates the per-step summarizer burn your repro exposes.

No session-corruption family connection: the compaction/end error bracket is balanced and durable, and the shadowed content is preserved by construction. The fix is a control-flow choice (hard throw for an expected condition), not a data-integrity repair.

[fan56]

"summary is not smaller" is a constraint that only exists because the backend asks a model to produce prose and then polices it. A deterministic backend has no such gate to misfire: dsh-dcp extracts structured facts (paths/commands/errors/todos/user quotes) with fixed output rules, zero LLM calls per compaction, and the official trigger/retention/lock semantics are inherited unchanged.

dsh plugin add @aiwayds/dsh-dcp

Independently, the reject-valid-short-summary behavior you documented still looks like a real compaction-basic bug worth fixing upstream — the deterministic option just stops depending on that code path.