Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Task registry maintenance can burn CPU quadratically with many tasks [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75708•Fetched 2026-05-02 05:31:18
View on GitHub
Comments
2
Participants
3
Timeline
10
Reactions
2
Author
glfruitglfruit
Participants
clawsweeper[bot]clawsweeper[bot]glfruitglfruitjared-rebeljared-rebel
Timeline (top)
subscribed ×4mentioned ×3commented ×2cross-referenced ×1

OpenClaw 2026.4.29 can spend sustained CPU in task registry maintenance when the task registry contains many records.

Root Cause

The hot path was caused by calling taskRegistryMaintenanceRuntime.listTaskRecords() inside the per-task maintenance loop before cleanupTerminalAcpSession(...). Since listTaskRecords() clones/sorts/maps the entire registry, this makes that part of maintenance O(n^2).

Fix Action

Fix

I have a minimal PR that reuses the existing tasks snapshot for cleanupTerminalAcpSession(current, tasks) and adds a regression test asserting the maintenance path does not relist records per task.

PR fix notes

PR #75709: fix: avoid quadratic task registry maintenance

Description (problem / solution / changelog)

Summary

  • Reuse the task snapshot already captured at the start of runTaskRegistryMaintenance() when checking terminal ACP session cleanup.
  • Avoid calling listTaskRecords() once per task; that function clones/sorts/maps the entire registry.
  • Add a regression test that verifies maintenance only lists task records for the initial sweep and final orphan cleanup, not per task.

Fixes #75708.

Validation

Validated on the 2026.4.29 owned fork with the same patch:

pnpm exec vitest run src/tasks/task-registry.test.ts

Result: 57 tests passed.

Note: this PR branch was prepared from current upstream/main. The separate PR worktree does not have its own node_modules, so I did not reinstall dependencies there just to rerun the same focused test.

Changed files

  • src/tasks/task-registry.maintenance.ts (modified, +1/-1)
  • src/tasks/task-registry.test.ts (modified, +43/-1)

Code Example

pnpm exec vitest run src/tasks/task-registry.test.ts
RAW_BUFFERClick to expand / collapse

Summary

OpenClaw 2026.4.29 can spend sustained CPU in task registry maintenance when the task registry contains many records.

What I observed

While validating an owned 2026.4.29 build on macOS, the gateway process repeatedly hit about one core of CPU during startup/maintenance. A V8 profile pointed at:

  • runTaskRegistryMaintenance
  • listTaskRecords()
  • ArrayMap / task record cloning and sorting

The hot path was caused by calling taskRegistryMaintenanceRuntime.listTaskRecords() inside the per-task maintenance loop before cleanupTerminalAcpSession(...). Since listTaskRecords() clones/sorts/maps the entire registry, this makes that part of maintenance O(n^2).

Expected behavior

A maintenance sweep should take one task snapshot per pass and reuse it for per-task cleanup decisions unless a fresh global snapshot is explicitly required.

Fix

I have a minimal PR that reuses the existing tasks snapshot for cleanupTerminalAcpSession(current, tasks) and adds a regression test asserting the maintenance path does not relist records per task.

Local validation

On the 2026.4.29 owned fork with the same patch:

pnpm exec vitest run src/tasks/task-registry.test.ts

Result: 57 tests passed.

extent analysis

TL;DR

The likely fix involves reusing the existing task snapshot for cleanup decisions to avoid redundant listing and sorting of task records.

Guidance

  • Review the runTaskRegistryMaintenance function to ensure it reuses the task snapshot for per-task cleanup decisions.
  • Verify that listTaskRecords() is not called unnecessarily within the maintenance loop.
  • Test the maintenance path with a large number of task records to ensure it no longer exhibits O(n^2) behavior.
  • Apply the proposed patch and run the regression test using pnpm exec vitest run src/tasks/task-registry.test.ts to validate the fix.

Example

No code snippet is provided as the issue already includes a proposed patch and test.

Notes

The fix assumes that reusing the task snapshot is sufficient to avoid the performance issue and does not introduce any other problems.

Recommendation

Apply the workaround by reusing the existing task snapshot for cleanup decisions, as it directly addresses the identified performance issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

A maintenance sweep should take one task snapshot per pass and reuse it for per-task cleanup decisions unless a fresh global snapshot is explicitly required.

#index setup#retrieval issue#search optimization#API routing#API middleware

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Task registry maintenance can burn CPU quadratically with many tasks [1 pull requests, 2 comments, 3 participants]