-
Notifications
You must be signed in to change notification settings - Fork 188
Decouple detail panel from trace viewer web worker pipeline #1017
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: 865a9f1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (42 failed)mongodb (1 failed):
turso (41 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
|
Contributor
Member
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Feb 12, 2026
f9343d5 to
42dad79
Compare
81ebf60 to
3f3fcaa
Compare
Decouple the EntityDetailPanel from the TraceViewerContextProvider so it no longer goes through the web worker's postMessage pipeline. Previously, the panel was rendered as a customPanelComponent inside the trace viewer context, which meant hydrated data (including non-structurally-cloneable types like URLSearchParams) had to survive the worker's structured clone boundary, causing DOMExceptions. Now the panel is rendered as a sibling to the trace timeline: - Timeline (inside TraceViewerContextProvider) handles span layout - Panel (outside context) receives data directly via props - A lightweight SelectionBridge component reads the selected span from context and passes it up to the parent via callback Changes: - WorkflowTraceViewer: flex layout with timeline + panel as siblings. Panel has its own width/resize state, independent of context. - EntityDetailPanel: remove useTraceViewer() dependency. Receives selected span info via new selectedSpan prop (SelectedSpanInfo). - TraceViewerContext: deprecate customPanelComponent field, remove setCustomPanelComponent action. - Export SelectedSpanInfo type from web-shared.
Now that the detail panel renders outside the trace viewer's web worker pipeline (no postMessage boundary), all types can be revived as proper instances: URLSearchParams, Headers, URL, etc. Strip input/output/error from step and run data embedded in trace span attributes to avoid sending hydrated objects through the web worker's postMessage boundary. The detail panel fetches full data separately via spanDetailData.
…l delta PanelResizeHandle was computing delta from the original startX on every pointermove, but the handler added it incrementally, causing exponential width growth during drag. Track lastX and send only the incremental change per move event.
6214b15 to
865a9f1
Compare
7889a91 to
c56dc38
Compare
Merge activity
|
karthikscale3
added a commit
that referenced
this pull request
Feb 13, 2026
Bring the web-shared trace/detail panel files back in sync with main so PR #1017 behavior is preserved and not regressed on this branch. Co-authored-by: Cursor <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

Summary
Render the
EntityDetailPanel(step/hook/event detail sidebar) outside the trace viewer'sTraceViewerContextProvider, so hydrated data no longer passes through the web worker'spostMessagestructured clone boundary.Problem
The trace viewer uses a web worker for span layout calculations, sending data via
postMessagewhich requires structured cloning. After moving hydration client-side, the hydrated data (containingURLSearchParams,Headers, and other non-structurally-cloneable types) was embedded in trace span attributes and sent to the worker, causingDOMException: URLSearchParams object could not be cloned.Solution
Render the detail panel as a sibling to the trace timeline instead of nested inside the context:
WorkflowTraceViewer: flex layout with timeline + panel as siblingsSelectionBridge: lightweight component inside context that reads the selected span and passes it up via callbackEntityDetailPanel: no longer importsuseTraceViewer(), receives selected span info viaselectedSpanpropinput/output/errorfrom trace span attributes to keep worker data lightweightAlso fixes
customPanelComponentbug — the panel was stored in context state during initialization and never updated, causing data to be lost on re-renders