The current implementation filters out all node executions whose status is `paused`. Please remove this logic, add unit / integration tests and execute relevant tests.
distinguish between the global timeout and node timeout.
For node-level timeout, the status should be updated to timeout.
for global timeout, the status should be updated to expired.
For status in (timeout, expired, SUBMITTED), the form should not be processed by the `check_and_handle_human_input_timeouts` logic.
only node-level timeout should resume the execution of workflow, global timeout should mark execution as STOPPED.
Update the documentation of HumanInputFormStatus to reflect the facts above.
Currently, the HumanInput node yields a `HumanInputFormFilledEvent` event while form is submmited. However, for form level timeout, current no event about timeout is emitted. This makes the frontend UI not updated while the events of time out are sent to the frontend.
Analysis this problem, propose a way to resolve this issue.
Previously the fields / classes are named with `placeholder`. However,
the actual purpose is to use as default values. This commit addresses
this problem by correcting names for relevant fields / classes.
- FormInputPlaceholder
- FormInput.placeholder
- HumanInputRequiredResponse.resolved_placeholder_values
- HumanInputFormDefinition.resolved_placeholder_values
- FormCreateParams.resolved_placeholder_values
- HumanInputRequired.resolved_placeholder_values
- The `resolved_placeholder_values` argument of _create_human_input_delivery_test_form
- The `resolved_placeholder_values` inside _jsonify_form_definition
The HumanInput node will pause the execution of workflow if execution, while WorkflowTool works in a blocking manner. (Receiving arguments and returning results once finished). The two mode are inherently incompatible.
The goal of this change is to forbid workflows containing HumanInput node being published as WorkflowTool.
Please check the current implementation and propose a solution.
Currently, the celery worker executing workflows / chatflows uses redis pubsub to publish events to api.
(See \_topic\_msg\_generator and \_publish\_streaming\_response)
The current implementation uses the default redis client.
For large scale deployment, we need to use a dedicated redis cluster to ensure performance.
To achieve this, you should:
1. introduce a dedicated configuration class to control
the redis address used for pubsub. (Ideally, there should only be one configuration item such as `pubsub_redis_url`, and its default value should be the original redis confugration.)
2. Add an option to switch between pubsub and sharded pubsub. When shared pubsub is specified, the ShardedRedisBroadcastChannel should be used instead.
COmplete the task above, add some unit tests.
Reason should be an enumeration with only one member `resumption` currently.
Please update these part of events:
- Graph / Engine Event (GraphRunStartedEvent)
- Queue event (QueueWorkflowStartedEvent)
- SSE response event (WorkflowStartStreamResponse)
Besides, you should remove the `is_resumption` flag for `node_started` events; including:
- Queue Event (`QueueNodeStartedEvent`)
- SSE Event (`NodeStartStreamResponse`)
- Node event (`NodeRunStartedEvent`)
After finishing the changes above, adjust related tests.
You should run the affected tests and ensure they can pass. (You should use `uv run pytest` to run tests)
Add the following length limit to UserAction fields:
- limit the length of `id` to 20 chars.
- limit the length of title to 40 chars.
Add some unit tests to ensure the validation rules are enforced.
The EmailDeliveryConfig in api/core/workflow/nodes/human\_input/entities.py has a field `debug_mode`. When this field is set to `True` in `node_data`, the test run (InvokeFrom.DEBUGGER) and the delivery test should only sent test emails to the current user, instead of sending to the specified recipients.
Please implement this logic, write correspond test cases to ensure that the logic works as expected.
This ensures that `HumanInputForm` could be associated to a specific
application without relying on `WorkflowRun`, providing us a smoother
migration path if we want to implement test form.
