[Bug] Context compaction indicator remains active after a failed compact request

[wibus-wee]

Affected area

Agent runtime / ACP

Installation method

Built from source

Lody version or commit

b4d5443

Operating system

macOS (exact version and architecture were not captured)

Agent or runtime

Codex ACP runtime

What happened?

When automatic context compaction starts and the remote compact request fails, Lody records a visible chat_failed notice and returns the Session to idle, but the composer continues to display "Compacting" indefinitely.

The durable history still contains the latest context_compaction tool call with pending or in_progress status. Reloading retains the stale indicator because the provider prompt error did not settle that activity.

Observed error:

Error running remote compact task: Connection failed: error sending request

The observed value can be a plain Error without a numeric ACP code, so settlement cannot depend only on ACP error parsing or a narrow disconnect-message allowlist.

What did you expect?

When a started provider prompt returns an error and is no longer in flight, Lody should persist unresolved context-compaction activity in that exact turn as failed so the transcript and usage footer converge after reload.

For cancellation, host finalization alone is not sufficient evidence. The compaction must remain active while the raw ACP prompt remains active. After raw completion or successful termination, the unresolved activity must become terminal before the execution owner is released. Failed termination must continue waiting for raw completion.

Explicit provider terminal updates must be preserved, including a late completed update for the same toolCallId.

How can we reproduce it?

1. Start a Codex turn whose context triggers automatic remote compaction.
2. Let the runtime emit a context_compaction tool call with pending or in_progress status.
3. Make the remote compact request fail with Error running remote compact task: Connection failed: error sending request before the runtime emits a terminal tool-call update.
4. Observe the corresponding failure and that the Session returns to idle.
5. Observe that the persisted compaction remains active after reopening the Session.

A deterministic prompt-lifecycle and history-finalization test can reproduce the host-side defect without a Model API Simulator. End-to-end model API failure injection is intentionally out of scope for the initial fix.

How often does it happen?

Every time the provider prompt fails after emitting a non-terminal compaction activity and before emitting its terminal update.

Relevant log output

Error running remote compact task: Connection failed: error sending request

Additional context

SessionHistory.finished is not evidence that the provider stopped because interrupted-turn teardown also stamps it. #571 now retains execution ownership until the raw ACP request settles or the old session is successfully terminated. #573 completes the state transition by settling unresolved compaction after that proof and before owner release.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.
• If I plan to submit a pull request, I will wait for a Lody maintainer to explicitly agree on the scope and approach before implementation.

[Dante-dan]

I traced the host-side path and found that isSessionContextCompacting only checks the latest compaction tool status, while markAssistantTurnFinished marks its owning assistant entry as finished without settling an incomplete compaction item. This matches the stale persisted indicator described here; I have not reproduced the remote provider failure itself.

I'd like to take this on as a focused fix: make the indicator respect the owning turn's terminal state, including existing saved history, and settle incomplete context-compaction activities when their owning turn is finalized. I will preserve completed tool results, unrelated/background tools, turn ownership, late terminal ACP updates, and the existing finalization timing behavior.

I will construct deterministic history and finalization tests covering pending/in-progress compaction followed by failure or cancellation, saved-history reload, repeated finalization, and a new compaction in the next turn. The initial change will stay within the host/UI boundary and will not require model API failure injection.