1.13.0 - Human-in-the-Loop and Workflow Execution Upgrades #32245
Replies: 2 comments 1 reply
-
|
weaviate always none |
Beta Was this translation helpful? Give feedback.
-
|
It's kind of funny — the feature is called Human-in-the-Loop, but users can't actually add a Human Input node inside the Loop node. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
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_attimestamp 8000 s (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.
Beta Was this translation helpful? Give feedback.
All reactions