1.13.0 - Human-in-the-Loop and Workflow Execution Upgrades #32245
QuantumGhost
announced in
Releases
Replies: 2 comments 1 reply
|
weaviate always none |
1 reply
|
Great release — the Human Input node is a meaningful addition that addresses a real gap in workflow design. The ability to pause execution at decision points and route based on human actions (approve/reject/escalate) makes workflows viable for use cases that previously required external orchestration or manual workarounds. Architecture / Deployment:
HITL Design:
Reliability fixes worth highlighting:
Solid work from the team and the new contributors. Looking forward to seeing how the HITL pattern evolves in future releases. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
🚀 New Features
Human-in-the-Loop (HITL)
We are introducing the Human Input node, a major update that transforms how AI and humans
collaborate within Dify workflows.
Background
Previously, workflows were binary: either fully automated or fully manual. This created a "trust gap" in
high-stakes scenarios where AI speed is needed but human judgment is essential. With HITL, we are making h
uman oversight a native part of the workflow architecture, allowing you to embed
review steps directly into the execution graph.
Key Capabilities
the subsequent path of the workflow.
🛠 Architecture Updates
To support the stateful pause/resume mechanism required by HITL and provide event‑subscription APIs, we refactored the execution engine: Workflow‑based streaming executions and Advanced Chat executions now run in Celery workers, while non‑streaming WORKFLOW runs still execute in the API process.
All pause/resume paths (e.g., HITL) are resumed via Celery, and events are streamed back through Redis Pub/Sub.
For Large Deployments & Self-Hosted Users:
We have introduced a new Celery queue named
workflow_based_app_execution. While standard setups will work out of the box, high-throughput environments should consider the following optimizations to ensure stability and performance:workflow_based_app_executionqueue based on your specific workload.PUBSUB_REDIS_URLenvironment variable to point to a dedicated Redis instance. Using Redis Cluster mode with Sharded PubSub is strongly advised to ensure horizontal scalability.New Celery Queue Required:
workflow_based_app_executionPlease ensure your deployment configuration (Docker Compose, Helm Chart, etc.) includes workers listening to the new
workflow_based_app_executionqueue.This queue is required for workflow‑based streaming executions and all resume flows (e.g., HITL); otherwise, streaming executions and resume tasks will not be processed.
🔧 Operational Note
Additional Celery Queue:
api_tokenIf
ENABLE_API_TOKEN_LAST_USED_UPDATE_TASK=true, ensure your deployment also has workers listening toapi_token.This queue is used by the scheduled batch update task for API token
last_used_attimestamps.⚙️ Configuration Changes
We have introduced several new environment variables to support the architectural changes. Large deployments should pay special attention to the PubSub Redis configurations to ensure scalability.
PUBSUB_REDIS_URL(Critical): Specifies the Redis URL used for PubSub communication between the API and Celery workers. If left empty, it defaults to the standardREDIS_*configuration.PUBSUB_REDIS_CHANNEL_TYPE(Critical): Defines the channel type for streaming events. Options arepubsub(default) orsharded. We highly recommend usingshardedfor high-throughput environments.PUBSUB_REDIS_USE_CLUSTERS(Critical): Set totrueto enable Redis cluster mode for PubSub. Combined with sharded PubSub, this is essential for horizontal scaling.Other Additions:
WEB_FORM_SUBMIT_RATE_LIMIT_MAX_ATTEMPTS: Maximum number of web form submissions allowed per IP within the rate limit window (Default:30).WEB_FORM_SUBMIT_RATE_LIMIT_WINDOW_SECONDS: Time window in seconds for web form submission rate limiting (Default:60).HUMAN_INPUT_GLOBAL_TIMEOUT_SECONDS: Maximum seconds a workflow run can stay paused waiting for human input before global timeout (Default:604800, 7 days).ENABLE_HUMAN_INPUT_TIMEOUT_TASK: Enables the background task that checks for expired human input requests (Default:true).HUMAN_INPUT_TIMEOUT_TASK_INTERVAL: Sets the interval (in minutes) for the timeout check task (Default:1).ENABLE_API_TOKEN_LAST_USED_UPDATE_TASK: Enables the periodic background task that batch-updates API tokenlast_used_attimestamps (Default:true).API_TOKEN_LAST_USED_UPDATE_INTERVAL: Sets the interval (in minutes) for batch-updating API tokenlast_used_attimestamps (Default:30).SANDBOX_EXPIRED_RECORDS_CLEAN_BATCH_MAX_INTERVAL: Maximum random delay (in milliseconds) between retention cleanup batches to reduce DB pressure spikes (Default:200).📌 Additional Changelog Highlights
Reliability & Correctness
Performance & Scalability
AppListApiquery optimizations.API & Platform Capabilities
Security
new Functionevaluation from ECharts parsing and now return explicit parsing errors for unsupported chart code.Localization
nl-NL) language support across backend language mapping and web localization resources.Upgrade Guide
Important
If you use custom
CELERY_QUEUES, make sureworkflow_based_app_executionis included.If
ENABLE_API_TOKEN_LAST_USED_UPDATE_TASK=true, also includeapi_token.For background and details, see⚠️ Important Upgrade Note and 🔧 Operational Note above.
Docker Compose Deployments
Back up your customized docker-compose YAML file (optional)
Get the latest code from the main branch
Stop the service. Please execute in the docker directory
Back up data
tar -cvf volumes-$(date +%s).tgz volumesUpgrade services
Note
If you encounter errors like below
Please use the following command instead. For details, please read this #28706
Source Code Deployments
Stop the API server, Worker, and Web frontend Server.
Get the latest code from the release branch:
Update Python dependencies:
cd api uv syncThen, let's run the migration script:
Finally, run the API server, Worker, and Web frontend Server again.
What's Changed
flask upgrade-dbfail on error by @longbingljw in fix: makeflask upgrade-dbfail on error #32024#i18nby @hyoban in chore: fix type for useTranslation in#i18n#32134workflow_based_app_executionqueue in start-worker script by @QuantumGhost in chore(api): consume tasks inworkflow_based_app_executionqueue in start-worker script #32214New Contributors
Full Changelog: 1.12.1...1.13.0
This discussion was created from the release 1.13.0 - Human-in-the-Loop and Workflow Execution Upgrades.
All reactions