Align workflow_task_schedule_to_start_latency

[Quinn-With-Two-Ns]

Align how workflow_task_schedule_to_start_latency is measured across the Async and Multithreaded Poller

sdk-java/temporal-sdk/src/main/java/io/temporal/internal/worker/WorkflowPollTask.java

Line 200 in 4631b16

ProtobufTimeUtils.toM3Duration(response.getStartedTime(), response.getScheduledTime()));

Now both pollers will use the time from the task to calculate workflow_task_schedule_to_start_latency, this also aligns with Core and Go

---

Note

Compute schedule-to-start latency for async workflow and activity pollers using task-provided timestamps instead of local time.

• Metrics:
  • Workflow poller: WORKFLOW_TASK_SCHEDULE_TO_START_LATENCY now computed from task timestamps (r.getStartedTime() → r.getScheduledTime()).
  • Activity poller: ACTIVITY_SCHEDULE_TO_START_LATENCY now computed from task timestamps (r.getStartedTime() → r.getCurrentAttemptScheduledTime()).

^{Written by Cursor Bugbot for commit 402f814. This will update automatically on new commits. Configure here.}

[cretz]

Any idea of what the practical time difference could be for users that may be monitoring this metric? I guess we can just call it out in release notes

[Quinn-With-Two-Ns]

clock skew between the Server and Worker, maybe some unaccounted for network time. The main issue is the async poller was measuring it differently then everywhere else which is a bug.

[cretz]

I see this same logic for activity, do we want to update that one to use the activity poll response start time too? I also saw this logic with Nexus, but no start time on its response (I also confirmed the activity and workflow started time fields on the response go as far back as Temporal, so we're safe for old server versions)

[Quinn-With-Two-Ns]

ah good catch, fixed