reele commented on PR #16776: URL: https://github.com/apache/dolphinscheduler/pull/16776#issuecomment-2468487492
@ruanwenjun I spent some time reading through the main code, and I believe we can directly write `scheduleTime` into `ScheduleWorkflowCommandParam` in `WorkflowScheduleTrigger.constructTriggerCommand`. It will be passed to `commandParams` and always propagated to sub-workflows. At runtime, it will be merged into `globalParams`, it‘s easy to retrieve `scheduleTime` with minimal changes. But there are still a few issues to resolve: 1. The master's failover process always takes over all workflows, including sub-workflows. So, when a sub-workflow is taken over, it can also retrieve the schedule time from `globalParams`. But there's an issue with failing over sub-workflow tasks; it triggers a new sub-workflow instance to run alongside the original master-taken-over sub-workflow. I prefer to directly take over the sub-workflow task rather than triggering a new sub-workflow, as the sub-workflow may contain many tasks. The issue is: https://github.com/apache/dolphinscheduler/issues/16767 2. Some task or parameter operations do not verify whether the workflow is a sub-workflow. As a result, numerous instances of workflowInstance.getScheduleTime() need to be assessed to decide whether they are within a sub-workflow or should be altered to utilize commandParams/globalParams operations. When I coded according to the latter approach, I modified 17 sections of the code. So do we really need to proceed in this manner for store schedule time for sub-workflow? 3. Currently, parameter runtime values are obtained in real-time, while `globalParams` stores the definition values. This causes the parameter view on the UI page to display the definition value rather than the runtime value. and also I think storing the runtime value may help with instance failover. -- 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]
