Part-of: https://github.com/kestra-io/kestra-ee/issues/4228
Encapsulate access the FlowInputOutput from the RunContext in a new InputAndOutput component with a currated list of supported methods used by plugins.
* fix: in LoopUntil, missing handle of submitted task in the resolveWaitForNext method
* fix: remove useless code that was generating duplicate taskrun
If a test mis-behave, for ex starting an execution but not terminating it, as the default termination grace period is 5mn it can take very long time to wait for post-test terminaison.
Switching to a termination grace period of 5s may help.
I also detect that the ExecutionControllerRunner test when launching the test suite, would not properly kill the `sleep-long` flow so waiting for it to complete, or the termination grace period. When a test that use this flow is launched separatly it works properly. As a safety net I reduce the sleep from 5mn to 30s.
* fix(executor): record CREATED/RUNNING/SUCCESS states for ExecutionUpdatableTask attempts
Previously, ExecutionUpdatableTask attempts were created with only the
terminal state, skipping RUNNING and causing zero duration and incorrect UI display.
Update attempts through all state transitions:
- CREATED → RUNNING before task.update() call
- RUNNING → terminal state after execution
This preserves complete state history and enables accurate duration tracking.
* refactor: simplify attempt creation in handleExecutionUpdatingTask
Remove null/empty check for attempts list as no attempts exist at this
execution stage. Create attempt directly with RUNNING state using
`new State().withState(State.Type.RUNNING)`.
This simplifies the code while maintaining correct state transitions
(CREATED → RUNNING → terminal).
* test(RuntimeLabels): add state transition assertions
for ExecutionUpdatableTask in Labels tests
Verify that ExecutionUpdatableTask attempts record complete state transitions
(CREATED → RUNNING → SUCCESS) across all Labels test scenarios
By evaluating multiple condition in a separate queue, we serialize their evaluation which avoir races when we compute the outputs for flow triggers.
This is because evaluation is a multi step process: first you get the existing condtion, then you evaluate, then you store the result. As this is not guarded by a lock you must not do it concurrently.
The race can still occurs if muiltiple executors run but this is less probable. A re-implementation would be needed probably in 2.0 for that.
Fixes https://github.com/kestra-io/kestra-ee/issues/4602
