Repository navigation
Task state transitions are not tracked #1222
Description
Task status attributes (e.g., submitted → working → completed) are reserved in the code but not activated. Task state transitions are invisible in traces.
Current Behavior
The span attribute for task status appears to be defined but never populated with actual values.
When a task transitions from submitted to working to completed, no span attribute records this transition.
Expected Behavior
Each SSE status event should carry a task.status attribute reflecting the current task state, enabling state-machine visualization and duration analysis per state.
Impact
Cannot track task progress through its lifecycle.
Cannot measure time spent in each task state.
Cannot build task state-machine visualizations in observability dashboards.
cf Issue #1132
Activity
sumitvairagar commentedon Oct 17, 2026
Hi @kabir @ehsavoie 👋
I'd like to work on this issue.
I can see that PR #1177 addresses streaming span duration and metrics (#1219, #1220), and PR #1229 addresses push notification tracing (#1217). Issue #1222 — task state transitions as typed, structured attributes — doesn't appear to be covered by either.
PR #1177's
OpenTelemetryStreamSubscriber.onNext()buffers every streaming event asitem.toString(). That captures the data but makes it unqueryable — you can't filter traces by state or build dashboards on it. The fix is to check forTaskStatusUpdateEventspecifically and extractstatus.state()as a typed attribute rather than a raw string dump.Two approaches depending on your preference:
Option A — before #1177 merges: implement
OpenTelemetryTaskStreamLifecycleHookinextras/opentelemetry/serveras a CDI@Alternative @Priority(1)bean implementingTaskStreamLifecycleHook. ItsonEvent()receives every persisted event and adds a structured span event forTaskStatusUpdateEvent. No changes toserver-common, no overlap with #1177.Option B — after #1177 merges: add the
TaskStatusUpdateEventspecific handling directly insideOpenTelemetryStreamSubscriber.onNext()as a targeted improvement on top of what's already there. Smaller change, no collision risk.Happy to go either direction — or a different approach entirely if you have one in mind. Let me know what works best.
ehsavoie commentedon Oct 19, 2026
#1177 is going to be split into several PRs as i'm going to change that to multi spans instead of events
sumitvairagar commentedon Oct 19, 2026
Thanks for the heads-up @ehsavoie — that makes sense, multi spans per state transition would be much cleaner for querying than buffered events.
With the redesign in mind, do you expect the new multi-span approach to cover typed task state attributes from
TaskStatusUpdateEvent(what #1222 is asking for), or will that remain an open gap once the new PRs land? Happy to wait and contribute on top of the new structure if there's still room for it.