Skip to content

fix(ui): reduce polling intervals to prevent progressive UI sluggishness#45930

Open
McMuff86 wants to merge 2 commits intoopenclaw:mainfrom
McMuff86:fix/ui-polling-intervals
Open

fix(ui): reduce polling intervals to prevent progressive UI sluggishness#45930
McMuff86 wants to merge 2 commits intoopenclaw:mainfrom
McMuff86:fix/ui-polling-intervals

Conversation

@McMuff86
Copy link
Copy Markdown

Problem

The Control UI polling intervals are very aggressive:

  • Nodes: every 5s
  • Logs: every 2s
  • Debug: every 3s

This causes excessive RPC traffic that leads to progressive dashboard slowdown — especially with many active sessions or when the dashboard is left open in a background tab.

Relates to #45698.

Changes

Reduced polling intervals to more reasonable defaults:

Poll Before After Rationale
Nodes 5s 30s Topology rarely changes
Logs 2s 5s Still near-realtime tail
Debug 3s 10s Status data is slow-moving

Also extracted magic numbers into named constants for maintainability.

Impact

  • ~85% reduction in polling RPC calls (from ~26/min combined to ~4/min)
  • No functional change — all polls still run, just less frequently
  • Logs tab remains responsive enough for live tailing
  • Nodes/Debug data is slow-moving enough that 30s/10s intervals are plenty

Testing

Verified on a local instance with 89 active sessions where the dashboard was noticeably sluggish before. After the change, CPU and network usage dropped significantly and the UI remained responsive.

Previous polling intervals (Nodes: 5s, Logs: 2s, Debug: 3s) caused
excessive RPC traffic that leads to progressive dashboard slowdown,
especially with many active sessions or when left open in a background
tab.

New intervals balance freshness with resource usage:
- Nodes:  30s (topology rarely changes)
- Logs:    5s (still near-realtime tail)
- Debug:  10s (status data is slow-moving)

Magic numbers replaced with named constants for maintainability.

Relates to openclaw#45698
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Mar 14, 2026

Greptile Summary

This PR reduces the polling frequencies for the three Control UI data feeds — nodes, logs, and debug — and extracts the previously inline magic numbers into named, documented constants. The changes are minimal, focused, and well-explained.

Key changes:

  • NODES_POLL_MS: 5 s → 30 s
  • LOGS_POLL_MS: 2 s → 5 s
  • DEBUG_POLL_MS: 3 s → 10 s
  • A JSDoc block documents the rationale for each interval directly above the constants

Observation (pre-existing, not introduced by this PR): startNodesPolling fires unconditionally on every tick regardless of the active tab, whereas startLogsPolling and startDebugPolling both guard behind a host.tab check before loading data. With the new 30-second interval this asymmetry is more visible — if the user is on a different tab, a stale nodes snapshot could be up to 30 s old when they switch back. A tab guard (or an immediate fetch on tab-switch) would eliminate that latency, but that's a follow-up concern rather than a blocker for this PR.

Confidence Score: 5/5

  • This PR is safe to merge — it is a purely numeric tweak with no logic changes and no risk of regression.
  • The diff touches a single file, replaces three hard-coded numeric literals with named constants, and does not alter any control flow. The new values are well-justified and the change is thoroughly documented inline.
  • No files require special attention.

Last reviewed commit: b3f5ae6

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 34af89795d

ℹ️ 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".

Comment thread ui/src/ui/app-polling.ts
* - Debug: 10 s (status data is slow-moving)
*/
const NODES_POLL_MS = 30_000;
const LOGS_POLL_MS = 5_000;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Restore a shorter logs polling interval

Increasing LOGS_POLL_MS to 5 s makes the Logs tab lose data on busy gateways, not just update less often. The UI still requests only 500 lines / 250 KB per poll (ui/src/ui/app.ts:431-432), and logs.tail explicitly resets to the last maxBytes chunk whenever size - cursor > maxBytes (src/gateway/server-methods/logs.ts:81-91). That means any gateway emitting more than ~250 KB over 5 seconds will skip older lines between polls and show only the newest chunk. With the previous 2 s cadence the threshold was much higher, so this is a functional regression for live tailing sessions that generate lots of logs.

Useful? React with 👍 / 👎.

@clawsweeper
Copy link
Copy Markdown
Contributor

clawsweeper Bot commented Apr 28, 2026

Codex review: needs changes before merge.

Summary
This PR extracts Control UI polling interval constants and changes Nodes/Logs/Debug polling from 5s/2s/3s to 30s/5s/10s in ui/src/ui/app-polling.ts.

Reproducibility: yes. for the PR-introduced regression by source inspection: if the active Logs tab falls more than the 250KB/500-line tail budget behind between cursor requests, readLogSlice resets to the newest window and older bytes are skipped. The original dashboard sluggishness claim was not locally reproduced here and remains based on reported runtime evidence.

Next step before merge
A narrow automated repair can preserve the useful constant extraction while restoring or loss-proofing Logs polling and adding the missing changelog entry.

Security
Cleared: The diff only changes Control UI TypeScript constants/comments and introduces no dependency, workflow, package, secret, permission, or code-execution surface.

Review findings

  • [P1] Keep log polling loss-resistant — ui/src/ui/app-polling.ts:21
  • [P3] Add the changelog entry — ui/src/ui/app-polling.ts:8
Review details

Best possible solution:

Ship a narrow Control UI polling cleanup that keeps named constants and lower-risk Nodes/Debug churn reduction, preserves active Logs live-tail semantics or makes cursor recovery lossless, and records the user-facing fix in the changelog.

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

Yes for the PR-introduced regression by source inspection: if the active Logs tab falls more than the 250KB/500-line tail budget behind between cursor requests, readLogSlice resets to the newest window and older bytes are skipped. The original dashboard sluggishness claim was not locally reproduced here and remains based on reported runtime evidence.

Is this the best way to solve the issue?

No, not as written. The safer fix is to keep the Logs cadence at 2s or implement lossless cursor catch-up before increasing it, while handling Nodes/Debug polling churn and the changelog separately.

Full review comments:

  • [P1] Keep log polling loss-resistant — ui/src/ui/app-polling.ts:21
    Changing LOGS_POLL_MS to 5s is not only a freshness tradeoff. The UI still asks logs.tail for the saved cursor with 500-line/250KB limits, and the server resets to the newest maxBytes window when the cursor is too far behind; busy gateways can skip bytes generated between polls. Restore the 2s cadence or make catch-up lossless before increasing it.
    Confidence: 0.91
  • [P3] Add the changelog entry — ui/src/ui/app-polling.ts:8
    This is a user-facing Control UI performance fix, but the PR only changes the polling file. Repo policy requires user-facing fix/perf changes to add an Unreleased changelog bullet, so release notes would miss the change.
    Confidence: 0.83

Overall correctness: patch is incorrect
Overall confidence: 0.92

Acceptance criteria:

  • pnpm --dir ui test -- src/ui/app-lifecycle-connect.node.test.ts src/ui/app-settings.test.ts src/ui/app-settings.refresh-active-tab.node.test.ts
  • pnpm test -- src/logging/log-tail.test.ts src/gateway/server-methods/server-methods.test.ts
  • pnpm exec oxfmt --check --threads=1 ui/src/ui/app-polling.ts CHANGELOG.md

What I checked:

  • PR slows active Logs polling: The PR head sets LOGS_POLL_MS = 5_000 and uses it for startLogsPolling, replacing current main's 2000 ms active Logs interval. (ui/src/ui/app-polling.ts:21, 34af89795d37)
  • Current main active Logs cadence: Current main only loads Logs while host.tab === "logs" and uses a 2000 ms polling interval. (ui/src/ui/app-polling.ts:37, 443f7035a2e5)
  • Bounded Control UI log requests: loadLogs sends the saved cursor with state.logsLimit and state.logsMaxBytes, so the amount of log output between polls affects whether the server can return all missed bytes. (ui/src/ui/controllers/logs.ts:111, 443f7035a2e5)
  • Default Logs tail budget: The Control UI defaults active Logs requests to 500 lines and 250,000 bytes. (ui/src/ui/app.ts:553, 443f7035a2e5)
  • Server reset behavior: When size - start > maxBytes, readLogSlice marks the response reset/truncated and starts at the newest maxBytes window, which can skip bytes older than that window. (src/logging/log-tail.ts:91, 443f7035a2e5)
  • Logs tab entry refresh: Switching to the Logs tab performs an immediate reset load, so the interval change mainly affects active live tailing after the tab is already open. (ui/src/ui/app-settings.ts:411, 443f7035a2e5)

Likely related people:

  • Peter Steinberger: Remote commit history shows Peter split ui/src/ui/app-polling.ts out with the original Nodes/Logs polling cadences and later introduced src/logging/log-tail.ts with the cursor/maxBytes reset behavior that makes the Logs cadence safety-sensitive. (role: introduced relevant polling/log-tail structure; confidence: high; commits: e3ff8c4d288b, 306fe841f54b; files: ui/src/ui/app-polling.ts, src/logging/log-tail.ts)
  • BunsDev: Authored and merged fix(control-ui): measure and decouple slow refreshes #75986, which added Control UI timing/refresh decoupling and explicitly triaged this PR as related but not superseded. (role: recent maintainer for adjacent Control UI responsiveness work; confidence: high; commits: 64fcc8a1aadb, 84c472c5abd5; files: ui/src/ui/app-settings.ts, ui/src/ui/control-ui-performance.ts, ui/src/ui/gateway.ts)
  • joshavant: Recent remote history shows several edits to ui/src/ui/controllers/logs.ts, including quiet-mode and payload-shape cleanup near the cursor handling used by active Logs polling. (role: recent logs controller maintainer; confidence: medium; commits: b658e5d35ccc, c882d40187e3, 2965dbd61cfd; files: ui/src/ui/controllers/logs.ts)
  • Vincent Koc: Remote history shows a recent app-polling.ts runtime-seam refactor, and the shallow local checkout's current-main blame routes the current polling file through recent Vincent commits. (role: recent maintainer of polling type seams; confidence: medium; commits: dbe2a97e802a, 443f7035a2e5; files: ui/src/ui/app-polling.ts)

Remaining risk / open question:

Codex review notes: model gpt-5.5, reasoning high; reviewed against 443f7035a2e5.

Copy link
Copy Markdown
Member

BunsDev commented May 2, 2026

Maintainer overlap triage after opening #75986:

This PR is related but not duplicate-closed or superseded by #75986. The scopes are different:

I would keep this PR deferred/needs-changes rather than close it as duplicate of #75986. The existing blockers still apply: preserve live log-tail semantics or restore the shorter logs cadence, and add the required changelog entry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants