web: read observability list views from world.analytics when available#2647
web: read observability list views from world.analytics when available#2647karthikscale3 wants to merge 3 commits into
Conversation
Route the runs/steps/events/hooks list server actions through the optional world.analytics namespace when the backend provides one, falling back to the runtime storage APIs otherwise. Events listing only uses the analytics path when no payload data is requested. Detail/get actions, streams, and mutations are unchanged.
🦋 Changeset detectedLatest commit: 4e802fe 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 |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
The Events tab and trace viewer derive step names and wait resumeAt from resolved event payloads, and the hooks table needs the secret token and ownerId for its resume/copy-token actions. The metadata-only analytics rows do not carry these, so only the runs and steps list views use world.analytics. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks — both findings are valid and addressed in The analytics rows are metadata-only, and both events and hooks have list-view dependencies on resolved payloads that those rows don't carry:
So I reverted |
The events list/trace consumers read only top-level eventType, correlationId, and createdAt; event payloads are loaded lazily per event via fetchEvent(..., 'all') on the runtime path. Map the flat analytics event rows into the runtime Event shape (reconstructing eventData.stepName) so fetchEvents and fetchEventsByCorrelationId can use the analytics read path when available. Hooks remain on the runtime path (they need the secret token + ownerId). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Follow-up ( After tracing every consumer of the events list, they read only top-level
The only mismatch was structural: the runtime Hooks remain on the runtime path — those genuinely need the secret So the analytics read path now covers runs, steps, and events; hooks stay on runtime. Typecheck diff vs base is empty (no new errors); biome clean. |
| eventType: event.eventType, | ||
| createdAt: event.createdAt, | ||
| ...(event.correlationId ? { correlationId: event.correlationId } : {}), | ||
| ...(event.specVersion !== undefined |
There was a problem hiding this comment.
The analyticsEventToEvent remap drops resumeAt, so on the analytics events path wait_created events lose their resume time, breaking the trace viewer's sleep-span end-time cap and the wait's displayed resume time.
1 participant
What changed
Routes the observability list server actions in
@workflow/webthrough theoptional
world.analyticsnamespace when the configured backend provides one,and falls back to the existing runtime storage APIs otherwise.
Updated list actions in
app/server/workflow-server-actions.server.ts:fetchRuns→world.analytics.runs.list(elseworld.runs.list)fetchSteps→world.analytics.steps.list(elseworld.steps.list)fetchEvents→world.analytics.events.list(elseworld.events.list)fetchEventsByCorrelationId→world.analytics.events.listByCorrelationId(else runtime)fetchHooks→world.analytics.hooks.list(elseworld.hooks.list)Behavior
need. Selection is a simple guard: use
world.analyticswhen present,otherwise the runtime storage API. Backends that don't implement
analytics(e.g. local/postgres) keep working unchanged.
(
!withData). When a caller asks for payloads, the action stays on theruntime path, which can resolve them.
runs.get,steps.get,events.get,hooks.get), stream actions, and mutations (cancel, recreate, wakeup, resumehook) continue to use the runtime storage APIs.
Notes
relies on the common fields, so listing is unaffected.
Stacking
Stacked on the
world.analyticsAPI PR (base branchcodex/workflow-analytics-apis). Merge that first; this should retarget to thedefault branch afterward.
Validation
@workflow/webhas no new type errors (pre-existing, unrelatederrors only; the changed file is clean).
pnpm exec biome check app/server/workflow-server-actions.server.tsMerge order
This work lands as a stack of four PRs on the
world.analyticsread-path:world.analyticsnamespace (basemain) — merge firstworld.analytics(stacked on Add workflow analytics world APIs #2234)world.analytics(stacked on Add workflow analytics world APIs #2234)#2648 and #2647 both depend only on #2234 and are independent of each other. #2652 builds on #2647. After #2234 merges to
main, the stacked PRs auto-retarget.