Skip to content

perf(whatsapp): narrow runtime setter entry#85589

Merged
RomneyDa merged 1 commit into
mainfrom
perf/whatsapp-runtime-setter
May 23, 2026
Merged

perf(whatsapp): narrow runtime setter entry#85589
RomneyDa merged 1 commit into
mainfrom
perf/whatsapp-runtime-setter

Conversation

@RomneyDa

@RomneyDa RomneyDa commented May 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Summary

  • add a narrow WhatsApp runtime-setter-api.ts entry that exports only setWhatsAppRuntime
  • point WhatsApp bundled channel registration at that setter-only entry instead of the broad runtime-api.ts barrel
  • match the common pattern already used by Slack, Discord, Telegram, and Matrix to keep bundled plugin registration from importing broad runtime barrels during startup

Estimated Load-Time Impact

From the post-#84649 cold-start CPU profile:

  • WhatsApp-attributed startup work was about 3.11s inclusive, or 17.9% of post-profile non-idle CPU
  • the broad extensions/whatsapp/runtime-api.ts import accounted for about 1.97s inclusive, or 11.3% of post-profile non-idle CPU
  • that runtime-api.ts path was 63.3% of the measured WhatsApp-attributed startup work
  • this PR is expected to remove most of that ~1.97s inclusive runtime-barrel import cost from bundled plugin registration, while leaving the remaining WhatsApp channel plugin import cost untouched

This is an estimate from CPU-profile inclusive stack attribution, not a new before/after benchmark. A follow-up cold-start profile should verify the realized wall-clock change.

Verification

  • node scripts/run-vitest.mjs extensions/whatsapp/index.test.ts
  • pnpm build
  • git diff --check

Notes

This follows the same runtime setter split already present in:

  • extensions/slack/runtime-setter-api.ts
  • extensions/discord/runtime-setter-api.ts
  • extensions/telegram/runtime-setter-api.ts
  • extensions/matrix/runtime-setter-api.ts

The broad WhatsApp runtime-api.ts remains intact for compatibility/runtime callers; bundled registration only needs the setter.

Autoreview was attempted with .agents/skills/autoreview/scripts/autoreview --mode local --no-web-search, but the helper's Codex runner failed before review because the local Codex config contains approval_policy = prompt, which that runner does not accept.

@openclaw-barnacle openclaw-barnacle Bot added channel: whatsapp-web Channel integration: whatsapp-web size: XS maintainer Maintainer-authored PR labels May 23, 2026
@clawsweeper

clawsweeper Bot commented May 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge.

Latest ClawSweeper review: 2026-05-23 03:04 UTC / May 22, 2026, 11:04 PM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
The PR adds extensions/whatsapp/runtime-setter-api.ts and changes WhatsApp bundled channel registration to load setWhatsAppRuntime from that narrow entry instead of runtime-api.ts.

Reproducibility: not applicable. this is a performance cleanup PR, not a bug report with a failing user flow. The PR body gives a profile-derived estimate, and I verified the current source path the patch narrows.

PR rating
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Summary: Small, coherent patch with no blocking findings; confidence is limited mainly by the absence of a fresh performance profile.

Rank-up moves:

  • Attach a fresh cold-start profile before merge if maintainers want the estimated performance gain verified rather than accepted as follow-up work.
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Real behavior proof
Not applicable: The contributor real-behavior proof gate is not applied here because this is a maintainer-labeled MEMBER PR; the body still reports focused test/build checks but no fresh after-patch profile.

Risk before merge

  • The realized cold-start improvement is unmeasured in this PR; the body estimates the win from an earlier CPU profile and explicitly calls for a follow-up profile to verify wall-clock impact.

Maintainer options:

  1. Decide the mitigation before merge
    Land the narrow setter-entry split if maintainers accept the profile-derived justification, with a follow-up profile or guardrail test only if they want stronger regression proof before merge.
  2. Pause or close
    Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge
No ClawSweeper repair lane is needed; the remaining decision is ordinary maintainer acceptance of a small maintainer-labeled performance PR and its proof level.

Security
Cleared: The diff only changes a local WhatsApp module specifier and adds a local re-export; it does not add dependencies, scripts, permissions, secret handling, or external code execution.

Review details

Best possible solution:

Land the narrow setter-entry split if maintainers accept the profile-derived justification, with a follow-up profile or guardrail test only if they want stronger regression proof before merge.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a performance cleanup PR, not a bug report with a failing user flow. The PR body gives a profile-derived estimate, and I verified the current source path the patch narrows.

Is this the best way to solve the issue?

Yes: using a setter-only top-level entry is the same maintainable pattern already used by Slack, Discord, Telegram, and Matrix, and it preserves runtime-api.ts for compatibility/runtime callers.

Label changes:

  • add P3: This is a small WhatsApp startup-performance cleanup with limited blast radius and no evidence of an urgent user-facing regression.
  • add rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🌊 off-meta tidepool, patch quality is 🐚 platinum hermit, and Small, coherent patch with no blocking findings; confidence is limited mainly by the absence of a fresh performance profile.
  • add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The contributor real-behavior proof gate is not applied here because this is a maintainer-labeled MEMBER PR; the body still reports focused test/build checks but no fresh after-patch profile.

Label justifications:

  • P3: This is a small WhatsApp startup-performance cleanup with limited blast radius and no evidence of an urgent user-facing regression.
  • rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🌊 off-meta tidepool, patch quality is 🐚 platinum hermit, and Small, coherent patch with no blocking findings; confidence is limited mainly by the absence of a fresh performance profile.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The contributor real-behavior proof gate is not applied here because this is a maintainer-labeled MEMBER PR; the body still reports focused test/build checks but no fresh after-patch profile.

Acceptance criteria:

  • node scripts/run-vitest.mjs extensions/whatsapp/index.test.ts
  • pnpm build
  • git diff --check
  • Optional: rerun the cold-start CPU profile from the PR body to verify realized wall-clock impact

What I checked:

Likely related people:

  • steipete: Current-main shallow blame and shortlog for the WhatsApp entry/runtime files and the channel-entry runtime setter path point to commit 44d5330, with CODEOWNERS also mapping @steipete for repository ownership metadata. (role: recent area contributor; confidence: medium; commits: 44d5330993ce; files: extensions/whatsapp/index.ts, extensions/whatsapp/runtime-api.ts, src/plugin-sdk/channel-entry-contract.ts)
  • RomneyDa: The author is a MEMBER on this PR and authored the related open cold-start performance investigation this PR cites, so they are the clearest routing candidate for the intended profile-driven optimization. (role: related performance work owner; confidence: medium; commits: 3afb30d29e8e; files: extensions/whatsapp/index.ts, extensions/whatsapp/runtime-setter-api.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 304ff68c7975.

@clawsweeper clawsweeper Bot added rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. labels May 23, 2026
@clawsweeper

clawsweeper Bot commented May 23, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper PR egg

✨ Hatched: 💎 rare Gilded Patch Peep

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

  • Merged PRs are hatchable.
  • Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
  • Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 💎 rare.
Trait: watches the merge queue.
Image traits: location merge queue dock; accessory lint brush; palette pearl, teal, and neon green; mood proud; pose waving from a small platform; shell starlit enamel shell; lighting subtle sparkle highlights; background delicate sparkle particles.
Share on X: post this hatch
Copy: My PR egg hatched a 💎 rare Gilded Patch Peep in ClawSweeper.

What is this egg doing here?
  • Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
  • The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
  • Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
  • The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
  • Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

@RomneyDa RomneyDa merged commit 463929d into main May 23, 2026
143 of 152 checks passed
@RomneyDa RomneyDa deleted the perf/whatsapp-runtime-setter branch May 23, 2026 03:59
@github-actions github-actions Bot mentioned this pull request May 23, 2026
Open
frankhli843 added a commit to gemmaclaw/gemmaclaw that referenced this pull request May 24, 2026
@frankhli843 @RomneyDa
@clawsweeper @zhangguiping-xydt @Takhoffman @jason-allen-oneal @steipete @itsuzef
fix(upstream-sync): selective cherry-picks from openclaw 58e9628..fa3…
2e56407 
…9bef (#232)

* perf(whatsapp): narrow runtime setter entry (openclaw#85589)

* fix openclaw#84857: skip CLI runtime harness preflight during compaction (openclaw#85862)

Summary:
- The PR skips agent-harness compaction preflight for provider-owned or configured CLI runtime sessions, adds claude-cli regression coverage, includes a changelog entry, and applies small test/type cleanups.
- Reproducibility: yes. at source level. Current main still routes provider-owned `claude-cli` runtime compaction preflight through harness selection, where `claude-cli` is not a registered embedded harness.

Automerge notes:
- PR branch already contained follow-up commit before automerge: fix openclaw#84857: skip CLI runtime harness preflight during compaction
- PR branch already contained follow-up commit before automerge: fix(clawsweeper): address review for automerge-openclaw-openclaw-8487…

Validation:
- ClawSweeper review passed for head 1dd8a88.
- Required merge gates passed before the squash merge.

Prepared head SHA: 1dd8a88
Review: openclaw#85862 (comment)

Co-authored-by: 张贵萍0668001030 <zhang.guiping@xydigit.com>
Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com>
Co-authored-by: clawsweeper[bot] <274271284+clawsweeper[bot]@users.noreply.github.com>
Approved-by: takhoffman
Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com>
# Conflicts:
#	CHANGELOG.md
#	extensions/meeting-notes/index.test.ts
#	extensions/meeting-notes/src/tool.ts
#	src/agents/harness/selection.test.ts
#	src/agents/harness/selection.ts
#	src/gateway/server-startup-post-attach.test.ts

* fix(sandbox): mount workspace skills read-only

* fix(sandbox): block bridge writes to workspace skills
# Conflicts:
#	src/agents/sandbox/fs-paths.ts

* fix(sandbox): block remote bridge writes to skills

* fix(sandbox): filter remote skill mounts by existing roots

* fix: harden sandbox skill mounts (openclaw#85591)

# Conflicts:
#	src/agents/sandbox/workspace-skills-bridge-readonly.test.ts

* fix: guard remote sandbox skill roots (openclaw#85591)

* fix: close remote sandbox skill symlink aliases (openclaw#85591)

* fix: preserve sandbox skill overlay precedence (openclaw#85591)

# Conflicts:
#	src/agents/sandbox/browser.create.test.ts
#	src/agents/sandbox/docker.config-hash-recreate.test.ts

* fix(backup): dereference archive hardlinks

# Conflicts:
#	src/commands/backup-verify.test.ts
#	src/infra/backup-create.test.ts
#	src/infra/backup-create.ts

* fix(backup): reject missing hardlink targets

* fix(whatsapp): serialize Error in auto-reply delivery log (openclaw#85777)

The auto-reply "delivery failed" log path passes a raw Error
under the `err` field. tslog's default JSON serialization
renders bare Error instances as `{}` because Error own data
properties are non-enumerable. Every delivery failure in
production therefore logs `err: {}`, forcing operators to
guess the underlying Baileys error from timestamp alone.

Convert Error to `{ type, message, stack }` plus own-enumerable
properties at the log site, so Boom-style subclass diagnostics
(output.statusCode, data) and custom OutboundDeliveryError
fields (stage, results) survive. Non-Error rejection values
pass through unchanged.

Tests cover Error, Error subclass (Boom-style), string
rejection, and object rejection paths.

AI-assisted: Claude Code (Opus 4.7) authored, codex review
locally addressed.
# Conflicts:
#	extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.test.ts
#	extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts

* chore: add model-runtime-aliases.ts from upstream (needed by selection.ts)

* chore: add model-runtime-policy.ts from upstream (needed by model-runtime-aliases.ts)

* fix: correct backup-create.ts writeTarArchiveWithRetry structure (cherry-pick conflict resolution artifact)

* fix: add missing upstream types and helpers for build compatibility

- Add AgentRuntimePolicyConfig to types.agents-shared.ts
- Add agentRuntime field to AgentModelEntryConfig, ModelDefinitionConfig, ModelProviderConfig
- Add models field to AgentConfig
- Add relativePathEscapesContainerRoot to sandbox/path-utils.ts
- Add backup-volatile-filter.ts from upstream (isVolatileBackupPath)
- Add writeTarArchiveWithRetry, buildExtensionsNodeModulesFilter to backup-create.ts
- Fix resolveConfiguredAgentHarnessPolicy -> resolveAgentHarnessPolicy in selection.ts

* fix: revert upstream-only harness restructuring and apply minimal c8b75a7 patch

The previous cherry-pick of c8b75a7 (and fa39bef duplicate) introduced
upstream-only files (v2.ts, policy.ts, result-classification.ts, etc.) that
depend on types not present in gemmaclaw, and corrupted several test files.

This commit reverts all wrongly-introduced upstream-only files to their
gemmaclaw branch-point state and applies only the actual c8b75a7 change:
- Add isCliRuntimeProvider/isCliRuntimeAliasForProvider guards to
  maybeCompactAgentHarnessSession to skip compaction preflight for CLI runtimes
- Add minimal gemmaclaw-compatible tests for the new skip behavior
- Remove dead code introduced by the rollback (staging-based archive helpers,
  unused imports, unreachable functions)
- Delete upstream-only meeting-notes extension files not in gemmaclaw
- Restore all test files to their gemmaclaw-compatible versions

* fix(backup): skip unreadable files in tar filter (EACCES from Docker root-owned files)

Docker git clones create root-owned .promisor files that are unreadable on the
host. Add accessSync R_OK check in tarFilter to skip such files gracefully.

Also fix sandbox tests to use real temp directories instead of hardcoded
/tmp/workspace paths for more robust test isolation.

* fix(whatsapp): wire onError into dispatcherOptions for delivery failure logging

The cherry-pick of f0ec730 added logWhatsAppReplyDeliveryError and
normalizeErrForLog but missed wiring onError in dispatcherOptions because
the upstream base already had the onError call site (added in a prior
upstream commit not in our range). Add the missing onError handler so
delivery failures are logged with serialized Error objects.

* fix(whatsapp): restore helper types and functions stripped by revert commit

Commit 0696195 was overly aggressive: it reverted upstream-only harness
files but also stripped ReplyDeliveryInfo, normalizeErrForLog, and
logWhatsAppReplyDeliveryError that were legitimately added by our
WhatsApp cherry-pick (2688cf4). Restore them so onError can call
logWhatsAppReplyDeliveryError correctly.

* fix: add whatsapp runtime-setter-api.js to bundled sidecar paths baseline

extensions/whatsapp/runtime-setter-api.ts was added by cherry-pick but
the generated baseline JSON was not updated. Run runtime-sidecars:gen to
add dist/extensions/whatsapp/runtime-setter-api.js.

---------

Co-authored-by: Dallin Romney <dallinromney@gmail.com>
Co-authored-by: clawsweeper[bot] <274271284+clawsweeper[bot]@users.noreply.github.com>
Co-authored-by: 张贵萍0668001030 <zhang.guiping@xydigit.com>
Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com>
Co-authored-by: Jason O'Neal <jason.allen.oneal@gmail.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Co-authored-by: Youssef Hemimy <53057646+itsuzef@users.noreply.github.com>
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 24, 2026
@RomneyDa @SebTardif
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
768c80d
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 24, 2026
@RomneyDa @SebTardif
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
c4d4692
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 24, 2026
@RomneyDa @SebTardif
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
92d2acc
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 24, 2026
@RomneyDa
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
e171021
galiniliev pushed a commit to galiniliev/openclaw that referenced this pull request May 25, 2026
@RomneyDa
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
5e0ef99
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 26, 2026
@RomneyDa @SebTardif
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
b45b5f6
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 26, 2026
@RomneyDa @SebTardif
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
cdea82a
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 26, 2026
@RomneyDa @SebTardif
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
37e7f4d
jameslcowan pushed a commit to jameslcowan/openclaw that referenced this pull request Jun 2, 2026
@RomneyDa
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
40ba2b2
SYU8384 pushed a commit to SYU8384/openclaw that referenced this pull request Jun 3, 2026
@RomneyDa
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
d6a3c5e
sablehead pushed a commit to sablehead/openclaw that referenced this pull request Jun 10, 2026
@RomneyDa
perf(whatsapp): narrow runtime setter entry (openclaw#85589)
ef94865
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

channel: whatsapp-web Channel integration: whatsapp-web maintainer Maintainer-authored PR P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. size: XS status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@RomneyDa