Align workflow_task_schedule_to_start_latency #2669
Conversation
| .record(ProtobufTimeUtils.toM3Duration(startedTime, r.getScheduledTime())); | ||
| .record(ProtobufTimeUtils.toM3Duration(r.getStartedTime(), r.getScheduledTime())); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
| .record(ProtobufTimeUtils.toM3Duration(startedTime, r.getScheduledTime())); | ||
| .record(ProtobufTimeUtils.toM3Duration(r.getStartedTime(), r.getScheduledTime())); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
ah good catch, fixed
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Quinn-With-Two-Ns
force-pushed
the
align_wft_schedule_to_start_latency
branch
from
3b581ea to
b84aa7a
Compare
Quinn-With-Two-Ns
force-pushed
the
align_wft_schedule_to_start_latency
branch
from
b84aa7a to
647f690
Compare
Align how
workflow_task_schedule_to_start_latencyis measured across the Async and Multithreaded Pollersdk-java/temporal-sdk/src/main/java/io/temporal/internal/worker/WorkflowPollTask.java
Line 200 in 4631b16
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