acoustic-carpenter-78188
03/25/2026, 5:24 AMEndTime field when reporting task completion via UpdateActionStatusRequest. The server then falls back to time.Now() as the end time, which can be significantly later than the actual task completion time. The duration is then calculated as time.Now() - created_at, which includes all queue time and processing delays.
What changes were proposed in this pull request?
• Added a terminalPhaseTimestamp() helper that extracts the OccurredAt timestamp from the last entry in the TaskAction's PhaseHistory when it represents a terminal phase (Succeeded, Failed, Aborted, TimedOut)
• Set EndTime in the UpdateActionStatusRequest using the actual completion timestamp from the TaskAction's phase history
• This ensures the run service computes an accurate duration based on when the task actually completed, not when the server processed the update
Files changed:
• actions/k8s/client.go — Added terminalPhaseTimestamp() helper and set EndTime in status request
• actions/k8s/client_test.go — Added integration test for EndTime inclusion and table-driven unit tests for terminalPhaseTimestamp()
How was this patch tested?
• TestNotifyRunService_UpdateActionStatusIncludesEndTime — verifies that notifyRunService sends the correct EndTime from PhaseHistory when a task succeeds
• TestTerminalPhaseTimestamp — table-driven test covering: empty history, non-terminal phase, and all 4 terminal phases (Succeeded, Failed, Aborted, TimedOut)
• All existing tests continue to pass
Check all the applicable boxes
• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.
• main
• #6583
• fix: send actual EndTime in UpdateActionStatus to fix inflated durations 👈
flyteorg/flyteacoustic-carpenter-78188
03/27/2026, 4:57 AMacoustic-carpenter-78188
03/27/2026, 4:31 PM