mengw15 commented on code in PR #8581:
URL: https://github.com/apache/texera/pull/8581#discussion_r4065695390
##########
frontend/src/app/workspace/service/execute-workflow/execute-workflow.service.ts:
##########
@@ -194,6 +202,30 @@ export class ExecuteWorkflowService {
return this.currentState;
}
+ /** How long the current run has been going, for a view that mounted after
it started. */
+ public getExecutionDuration(): number {
Review Comment:
`getExecutionDuration()` returns the value from the last
`ExecutionDurationUpdateEvent`, and the backend sends that event only twice per
run: once when `startTimeStamp` is written, once when `endTimeStamp` is
(`ExecutionStatsService.scala:153-175`). The first one carries `currentTime -
newState.startTimeStamp` computed right after the timestamp is written
(`WorkflowExecutionService.scala:159`), so its value is a few milliseconds. The
per-second advance is local to each view's `timer(1000, 1000)`; nothing
advances the cached number.
So the cache holds ~0 for the whole run. A view that mounts 60s in seeds ~0
and shows `0s` — and its own ticker sits downstream of `switchMap` on the event
stream, so with no event following the hand-over it never starts. The clock
stays frozen at `0s` until the run ends, which is the symptom the comment above
described.
The new spec passes because the harness stubs `getExecutionDuration: () =>
execution.duration` and the test sets that to 42000; it covers the form reading
the getter, not what the real service returns.
This needs an anchor rather than a snapshot — keep `{duration, at:
Date.now(), isRunning}` and return `isRunning ? duration + (Date.now() - at) :
duration` — plus something to start the new view's ticker. Moving the clock
into this service as a value stream both views subscribe to would do both and
drop the duplicated `timer` in the two views.
The other two are right: the computing-unit branch now defers to
`reapplyExecutionLock`, and `showFailureIfAny` runs after `readConfig`, so the
fields exist for `hasEmptyRequiredInputs`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
