Frontend Migration: Deprecate Simulator API and adopt Braidpool RPC#456
Frontend Migration: Deprecate Simulator API and adopt Braidpool RPC#456priyashuu wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR migrates the dashboard’s BraidPool DAG frontend away from the deprecated Simulator API and toward consuming Braidpool RPC-derived data via the main WebSocket stream (dependency: #427).
Changes:
- Renames DAG graph payload field from
highest_work_pathtohighestWorkPathand updates consumers. - Switches the DAG visualization to subscribe to
MAIN_WEBSOCKETand filter forbraidpool_bead_infomessages. - Adds server-side scaffolding to fetch and broadcast braidpool bead/DAG info over WebSocket.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| import { fetchPoolInfo } from './utils/fetchPoolInfo.js'; | ||
| import { fetchMempoolStats } from './utils/fetchMempoolStats.js'; | ||
|
|
||
| import { fetchBraidpoolBeadInfo } from './utils/fetchbeadinfo.js'; |
There was a problem hiding this comment.
The new import ./utils/fetchbeadinfo.js does not exist in dashboard/api/utils in this PR branch, so the WebSocket server will fail to start with a module-not-found error. Either add/rename the utility to match the import (and case), or update the import to the correct existing module path/name (and ensure this PR includes it if CI runs on this branch).
| import { fetchBraidpoolBeadInfo } from './utils/fetchbeadinfo.js'; | |
| import { fetchBraidpoolBeadInfo } from './utils/fetchBeadInfo.js'; |
| async function sendBeadInfo() { | ||
| try { | ||
| const braidpoolData = await fetchBraidpoolBeadInfo(); | ||
|
|
||
| console.log( | ||
| '[sendBeadInfo] Received braidpool data:', | ||
| JSON.stringify(braidpoolData, null, 2) | ||
| ); | ||
|
|
||
| if (braidpoolData?.braidInfo) { | ||
| const payload = { | ||
| type: 'braidpool_bead_info', | ||
| data: { | ||
| braidInfo: braidpoolData.braidInfo, | ||
| peerInfo: braidpoolData.peerInfo, | ||
| highestWorkPath: braidpoolData.highestWorkPath, | ||
| cohorts: braidpoolData.cohorts, | ||
| parents: braidpoolData.parents, | ||
| children: braidpoolData.children, | ||
| }, | ||
| time: new Date().toLocaleString(), | ||
| }; | ||
|
|
||
| wss.clients.forEach((client) => { | ||
| if (client.readyState === client.OPEN) { | ||
| client.send(JSON.stringify(payload)); | ||
| } | ||
| }); | ||
| } | ||
| } catch (err) { | ||
| console.error('[Server] fetchBraidpoolBeadInfo failed:', err.message); | ||
| } | ||
| } |
There was a problem hiding this comment.
sendBeadInfo() is defined but never invoked in the interval loop, so no braidpool_bead_info messages will be broadcast to the frontend. Call sendBeadInfo() from the existing setInterval (with appropriate error handling) so the DAG component actually receives updates.
| console.log( | ||
| '[sendBeadInfo] Received braidpool data:', | ||
| JSON.stringify(braidpoolData, null, 2) | ||
| ); |
There was a problem hiding this comment.
Logging the entire braidpoolData via JSON.stringify(..., null, 2) on every polling cycle can generate very large logs and impact performance/operations in production. Consider removing this, reducing it to a small summary (counts), or gating it behind a debug/env flag.
priyashuu
force-pushed
the
deprecated_simulator
branch
from
f07a5a7 to
ac647d6
Compare
mcelrath
left a comment
mcelrath
left a comment
There was a problem hiding this comment.
This is a small fix, but there were some comments from the AI, can you respond to these?
● Below are the expanded details for each PR #456 finding.
- Perf (medium): main WS JSON.parse filtering
Where: dashboard/src/components/BraidPoolDAG/BraidPoolDAG.tsx
Why it matters: The component now listens to the main, multiplexed WebSocket and parses every incoming message just to
filter for DAG updates. If that main feed is high‑frequency (multiple message types, large payloads), repeated JSON.parse
- type checks on the UI thread can create frame drops and input jank, especially when DAG rendering is already busy.
Risk profile: Doesn’t break correctness, but under heavy traffic it can noticeably degrade UI responsiveness.
Suggested fix: Prefer server‑side routing to a dedicated DAG channel, or include a lightweight message envelope that
allows filtering without full parse (e.g., a small prefix/type field), or split the WS feed for DAG updates.
-
Perf (low): per‑tail Array.from + Math.max
Where: dashboard/src/components/BraidPoolDAG/BraidPoolDAGUtils.ts
Why it matters: For each update, the code allocates arrays from Sets and then computes Math.max(...). With large DAGs and
frequent updates, these allocations add GC pressure.
Risk profile: Minor overhead; not a correctness issue.
Suggested fix: Iterate the Set directly (manual max loop) to avoid allocations. -
TS (low): console.log in WS handler
Where: dashboard/src/components/BraidPoolDAG/BraidPoolDAG.tsx
Why it matters: Leaving logs in production can be noisy and can add small runtime overhead, and can leak data if logs
include payload content.
Risk profile: Low.
Suggested fix: Guard logs behind import.meta.env.DEV or remove entirely.
…and data reception refactor(BraidPoolDAGUtils): optimize parent node position calculation logic
Overview
This PR depends on another PR and should be merged after it. It introduces frontend changes to deprecate the Simulator API and switch all data fetching to Braidpool RPC methods. The UI now displays Braidpool data instead of simulator data.
Changes
Dependency