The file path is: api/controllers/web/human\_input\_form.py.
I have checked the implementation of RateLimiter and suspect this is a bug of the RateLimiter class.
Try to use TDD way to locate and fix this issue.
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.
I have fixed a bug in `_RedisShardedSubscription` in the latest commit. I need you to write an integration test case for this bug.
You should write the test in TDD way. You are free to change the git head.
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.
Avoid drain_queue and race condition caused by drain queue.
The current approach starts a background thread and buffer in-fly events
to an intermediate queue.Queue. The queue is bound and will drop events
once it's full.
