[web-shared] [cli] Refactor observability data fetching#1261
[web-shared] [cli] Refactor observability data fetching#1261VaguelySerious merged 49 commits intomainfrom
Conversation
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
🦋 Changeset detectedLatest commit: 2af0bf5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
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 |
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
workflow with 1 step💻 Local Development
▲ Production (Vercel)
workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (56 failed)mongodb (3 failed):
redis (2 failed):
turso (51 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
|
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
- Fetch events with withData:true so stepName, token, resumeAt are available - Fix sleep span runId extraction from wait entity data in detail panel
Count step_started events as attempts instead of relying on step_retrying. Clear completedAt on retry/re-start so a retried step doesn't retain stale timestamps.
- Show spinner + 'Loading more events...' while paginating - Show 'Waiting for more events...' when all pages loaded but run still active - Render trace viewer immediately when run exists (don't wait for isLoading) - Add footer prop to TraceViewerTimeline for content below spans in scroll area
Guard buildTrace on run.runId instead of just truthiness, since the
hook returns {} as WorkflowRun before data arrives.
Footer was rendered inside the timeline scroll container's fixed-height content div, making it invisible. Move to an absolute overlay at the bottom of the traceViewerContent area with a gradient fade. Visualize known vs unknown time in trace viewer - Active child spans (steps/hooks/sleeps without an end event) now cap at the latest known event time instead of `now`, so they only extend as far as our data goes — even if the run is completed but we haven't loaded all events yet. - buildTrace returns knownDurationMs (time from trace start to latest event). - Horizontal overlay in the trace viewer covers the region to the right of the known time horizon, indicating unloaded data. - Footer overlay shows 'Loading more events...' or 'Waiting for more events...' at the bottom of the timeline. Fix footer position: anchor to outermost trace viewer container The footer was inside .traceViewerContent which has a computed height smaller than the visible area. Moved to be a direct child of .traceViewer which has position:relative and fills the full visible height. Show 'End of run' in footer when run is complete and all events loaded Diagonal stripe pattern for unknown-time overlay - Black/dark-gray diagonal stripes instead of flat gray - Offset 5% from the known-time edge so stripes don't touch spans - CSS mask fades the pattern in from left to right
Footer: move back inside timeline scroll container with min-height wrapper so it's only visible when scrolled to the bottom, not overlaying content. Stripes: use --ds-gray-200/--ds-gray-400 CSS variables so the pattern is visible on both light and dark themes.
No transparency needed since the overlay fully covers the background. Uses design system tokens that correctly contrast in both light and dark.
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
- Remove leftover 300ms artificial delay in fetchEvents RPC call - Fix loading state never clearing for hook/sleep resources in useWorkflowResourceData (wrap in try/finally) - Add receivedCount, lastReceivedAt, and disposedAt to AttributePanel so the hook detail sidebar shows how often the hook was resolved Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
| attribute as keyof typeof attributeToDisplayFn | ||
| ]?.(displayData[attribute as keyof typeof displayData]); | ||
| const isModuleSpecifier = attribute === 'moduleSpecifier'; | ||
| const shouldCapitalizeLabel = attribute !== 'workflowCoreVersion'; |
There was a problem hiding this comment.
I thought maybe we'd not want to capitalize in general. Will revert, discuss separately
|
Tested hook resolution, sleeps, trace viewer pagination on a 200 step run and metadata rendering on the spans. Mostly looks good to me. Only minor nit: we may show a partial step/span at the pagination boundary if events for that step are split between pages - I think we are okay with this for now? We could potentially make the server do some pre-processing of the events list that has no partial events maybe. But we can ITG this. |
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
This PR refactors Web UI and CLI to build spans from events instead of fetching steps/hook.
This was a bit hard to do - now that we're loading events sequentially and constructing spans accordingly, we need to cleverly show the expected durations of spans/hooks that might not be resolved until much later. This probably deserves some thorough testing against larger runs.