Fix: Debounce dashboard loads and cap initial sync processing#623
Fix: Debounce dashboard loads and cap initial sync processing#6239chait9 wants to merge 1 commit into
Conversation
Addresses issue rohitg00#609 by implementing the following changes to src/viewer/index.html: - Introduced a debouncing mechanism for loadDashboard() calls to prevent excessive reloads during rapid updates, coalescing multiple calls into a single one after a short delay. - Implemented an in-flight guard to prevent multiple concurrent loadDashboard() executions. - Modified the WebSocket 'sync' message handling to ignore per-item processing of large initial sync payloads for the dashboard tab, preventing browser freezing and resource exhaustion. A single debounced dashboard load will now be triggered after the initial sync. These changes significantly improve the viewer dashboard's performance and responsiveness, especially when dealing with large historical data backlogs.
|
@9chait9 is attempting to deploy a commit to the rohitg00's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Fixes #609
This PR addresses the viewer dashboard freezing issue (Issue #609) by implementing several performance enhancements to
src/viewer/index.html:loadDashboard()calls are now debounced, preventing excessive reloads when multiple rapid updates occur (e.g., during a large WebSocketsyncevent). This coalesces multiple calls into a single update after a 300ms delay.loadDashboard()operation is in progress at a time, preventing race conditions and redundant data fetches.syncmessage handler now explicitly skips per-item processing of large historical data payloads for the dashboard tab during the initial connection. This prevents the dashboard from attempting to render thousands of observations individually, which previously led to browser freezing and high memory consumption. A single debounced dashboard load will still occur after the initial sync to reflect the current state.These changes significantly improve the viewer dashboard's responsiveness and stability, especially when dealing with large agent memory backlogs.