feat: send compaction start and completion notices by feniix · Pull Request #67830 · openclaw/openclaw

feniix · 2026-04-16T21:30:52Z

Summary

Problem: agents.defaults.compaction.notifyUser only surfaced a start notice, so messaging users could still see a long silent pause until the final reply arrived.
Why it matters: on Discord, Telegram, WhatsApp, and similar channels, silent compaction looks like the agent stalled or ignored the message.
What changed: reuse the existing agents.defaults.compaction.notifyUser config to send both 🧹 Compacting context... and 🧹 Compaction complete, add targeted coverage for the completion notice path, and update the config/docs wording to match.
What did NOT change (scope boundary): this does not add a new config key, does not enable verbose mode, and does not change block streaming behavior.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes Feature: compactionNotices config option for compaction-only notifications #58758
Related Feature: compactionNotices config option for compaction-only notifications #58758
This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

Root cause: N/A
Missing detection / guardrail: the notify-user flow had coverage for compaction start notices but not for completion notices.
Prior context (git blame, prior PR, issue, or refactor if known): existing behavior already supported start notices via notifyUser; this PR extends that same surface to cover completion.
Why this regressed now: N/A
If unknown, what was ruled out: N/A

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should have caught this. Otherwise write N/A.

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/reply/agent-runner-execution.test.ts
Scenario the test should lock in: when agents.defaults.compaction.notifyUser is enabled and compaction completes successfully, the messaging surface receives both the start and completion notices.
Why this is the smallest reliable guardrail: this is the narrowest reply-layer seam that owns compaction notice delivery to messaging channels.
Existing test that already covers this (if any): the file already covered silent-by-default behavior and start notices.
If no new test is added, why not: N/A

User-visible / Behavior Changes

agents.defaults.compaction.notifyUser: true now sends a completion notice in addition to the existing start notice.
Docs/config help now describe start + completion notices instead of start-only wording.

Diagram (if applicable)

Before:
[user message] -> [auto-compaction starts] -> [silent pause] -> [final reply]

After:
[user message] -> [🧹 Compacting context...] -> [auto-compaction] -> [🧹 Compaction complete] -> [final reply]

Security Impact (required)

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

Repro + Verification

Environment

OS: macOS
Runtime/container: local repo test run
Model/provider: N/A
Integration/channel (if any): messaging reply path
Relevant config (redacted): agents.defaults.compaction.notifyUser: true

Steps

Enable agents.defaults.compaction.notifyUser.
Trigger a compaction start event followed by a successful compaction end event.
Observe reply delivery through the messaging block-reply path.

Expected

The user sees 🧹 Compacting context... when compaction starts.
The user sees 🧹 Compaction complete when compaction finishes.
Verbose mode and block streaming remain unchanged.

Actual

After this change, the targeted tests confirm both notices are emitted through the reply layer.

Evidence

Attach at least one:

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

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: ran targeted Vitest coverage for the reply-layer compaction notice flow and config-help/schema checks.
Edge cases checked: silent-by-default behavior remains covered; custom onCompactionStart / onCompactionEnd callbacks still keep precedence over default notice delivery.
What you did not verify: no manual Discord/Telegram/WhatsApp end-to-end run in this branch.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

Backward compatible? (Yes/No) Yes
Config/env changes? (Yes/No) No
Migration needed? (Yes/No) No
If yes, exact upgrade steps:

Risks and Mitigations

Risk: channels that surface compaction notices could now show one extra status message per successful compaction.
- Mitigation: behavior stays behind the existing opt-in agents.defaults.compaction.notifyUser flag and does not affect the default silent mode.

greptile-apps · 2026-04-16T21:34:41Z

Greptile Summary

This PR extends agents.defaults.compaction.notifyUser to send both a start notice ("🧹 Compacting context...") and a completion notice ("🧹 Compaction complete") to messaging users, where previously only the start notice was sent. The change adds a unified sendCompactionNotice helper, guards completion notices behind completed === true, mirrors the existing onCompactionEnd callback precedence pattern from onCompactionStart, updates config help text and generated schema, and adds targeted Vitest coverage for the new completion path.

Confidence Score: 5/5

Safe to merge — the completion notice is gated behind the existing opt-in flag and all P0/P1 paths are unchanged.

Both findings are P2: one is a niche UX edge case for compaction failures (which almost always surface a separate error payload anyway), and the other is a missing test for a code path whose logic is directly symmetric with already-tested start-notice behavior. No correctness, data-integrity, or security issues were found.

No files require special attention.

Comments Outside Diff (1)

src/auto-reply/reply/agent-runner-execution.test.ts, line 272-318 (link)

Missing test: notifyUser: true with onCompactionEnd provided

The test verifies that custom callbacks fire when notifyUser is off. But there's no test for the inverse scenario (notifyUser: true and onCompactionEnd provided), which should suppress the end notice in favour of the custom callback. The precedence logic mirrors onCompactionStart, so it's almost certainly correct, but an explicit test would lock in the contract symmetrically with the existing start-notice coverage.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/auto-reply/reply/agent-runner-execution.test.ts
Line: 272-318

Comment:
**Missing test: `notifyUser: true` with `onCompactionEnd` provided**

The test verifies that custom callbacks fire when `notifyUser` is _off_. But there's no test for the inverse scenario (`notifyUser: true` _and_ `onCompactionEnd` provided), which should suppress the end notice in favour of the custom callback. The precedence logic mirrors `onCompactionStart`, so it's almost certainly correct, but an explicit test would lock in the contract symmetrically with the existing start-notice coverage.

How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/auto-reply/reply/agent-runner-execution.ts
Line: 530-538

Comment:
**No end notice when compaction starts but doesn't complete**

When `notifyUser: true` and a compaction event fires with `phase === "end"` but `completed !== true` (i.e., compaction ran but didn't finish successfully), users will see "🧹 Compacting context..." with no follow-up message. In most failure scenarios the agent turn also fails and the user gets an error payload, so it's rarely noticed in practice — but the asymmetry is worth being aware of. A "🧹 Compaction incomplete" notice (or clearing the start notice) could improve UX for the edge case where the session continues after an incomplete compaction.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/auto-reply/reply/agent-runner-execution.test.ts
Line: 272-318

Comment:
**Missing test: `notifyUser: true` with `onCompactionEnd` provided**

The test verifies that custom callbacks fire when `notifyUser` is _off_. But there's no test for the inverse scenario (`notifyUser: true` _and_ `onCompactionEnd` provided), which should suppress the end notice in favour of the custom callback. The precedence logic mirrors `onCompactionStart`, so it's almost certainly correct, but an explicit test would lock in the contract symmetrically with the existing start-notice coverage.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Agents: send compaction start and comple..." | Re-trigger Greptile}

greptile-apps · 2026-04-16T21:34:45Z

                    const completed = evt.data?.completed === true;
                    if (phase === "end" && completed) {
                      attemptCompactionCount += 1;
-                      await params.opts?.onCompactionEnd?.();
+                      if (params.opts?.onCompactionEnd) {
+                        await params.opts.onCompactionEnd();
+                      } else if (shouldNotifyUserAboutCompaction) {
+                        await sendCompactionNotice("end");
+                      }
                    }


No end notice when compaction starts but doesn't complete

When notifyUser: true and a compaction event fires with phase === "end" but completed !== true (i.e., compaction ran but didn't finish successfully), users will see "🧹 Compacting context..." with no follow-up message. In most failure scenarios the agent turn also fails and the user gets an error payload, so it's rarely noticed in practice — but the asymmetry is worth being aware of. A "🧹 Compaction incomplete" notice (or clearing the start notice) could improve UX for the edge case where the session continues after an incomplete compaction.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/auto-reply/reply/agent-runner-execution.ts Line: 530-538 Comment: **No end notice when compaction starts but doesn't complete** When `notifyUser: true` and a compaction event fires with `phase === "end"` but `completed !== true` (i.e., compaction ran but didn't finish successfully), users will see "🧹 Compacting context..." with no follow-up message. In most failure scenarios the agent turn also fails and the user gets an error payload, so it's rarely noticed in practice — but the asymmetry is worth being aware of. A "🧹 Compaction incomplete" notice (or clearing the start notice) could improve UX for the edge case where the session continues after an incomplete compaction. How can I resolve this? If you propose a fix, please make it concise.

feniix · 2026-04-16T21:49:59Z

Code review

Found 1 issue:

src/config/schema.base.generated.ts is edited directly, but the file header states "Auto-generated by scripts/generate-base-config-schema.ts. Do not edit directly." The PR updates src/config/schema.help.ts (the source of truth) correctly, but the generated file should be regenerated via pnpm config:docs:gen rather than hand-edited. Additionally, docs/.generated/config-baseline.sha256 is not updated. (CLAUDE.md says "If you change config schema/help or the public Plugin SDK surface, run the matching gen command and commit the updated .sha256 hash file.")

https://github.com/openclaw/openclaw/blob/ef9e6ecdfe7dd96be554795a08065b7957845491/src/config/schema.base.generated.ts#L1-L2
https://github.com/openclaw/openclaw/blob/ef9e6ecdfe7dd96be554795a08065b7957845491/src/config/schema.base.generated.ts#L4585-L4587

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 65f8dd582b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-20T16:43:52Z

+                      } else if (shouldNotifyUserAboutCompaction) {
+                        await sendCompactionNotice("incomplete");


Respect onCompactionEnd for incomplete compaction events

When compaction ends with completed !== true, this branch still emits the fallback 🧹 Compaction incomplete notice whenever notifyUser is enabled, even if the caller already provided onCompactionEnd. Channels that wire custom compaction UX callbacks (for example extensions/telegram/src/bot-message-dispatch.ts:915-933 and extensions/discord/src/monitor/message-handler.process.ts:921-933) can then show an unexpected extra chat message during failed/incomplete compactions, which breaks callback precedence established for start/completed events. Gate this fallback on !params.opts?.onCompactionEnd as well.

Useful? React with 👍 / 👎.

- Regenerate config baseline sha256 (pnpm config:docs:gen) - Add incomplete compaction notice when compaction ends without completing - Add test for onCompactionEnd callback precedence over notifyUser notice - Add test for incomplete compaction notice delivery

jalehman · 2026-04-20T18:55:24Z

Merged via squash.

Prepared head SHA: abedf6cf1104df231a629bb880987b916c7eae3a
Merge commit: f48d040bf523a23ce20b5141ca2d991bbcb82aa6

Thanks @feniix!

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: abedf6cf11

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-20T18:58:34Z

+                      } else if (shouldNotifyUserAboutCompaction) {
+                        await sendCompactionNotice("incomplete");


Skip incomplete notice during retrying compaction

This branch sends 🧹 Compaction incomplete for every phase === "end" event with completed !== true, but compaction retry events can legitimately end with completed: false and willRetry: true before a later successful retry. In that case, users with notifyUser enabled will see a misleading failure notice even though compaction is still in progress and may complete moments later. Please gate the incomplete notice on a non-retrying terminal end (for example, when willRetry is not true) to avoid false alarm messages.

Useful? React with 👍 / 👎.

@jalehman