这两位的情况其实已经把线索给得很全了，我帮你们汇总一下“怎么刹车 + 怎么清理 + 怎么避免再次卡死”，都针对 1.11.4。
I. What phenomenon are you currently encountering?
Based on Niklaus1028’s logs, it’s roughly:
- Continuously polling APIs like
/plugin/<plugin-id>/management/install/tasks, /dispatch/model/schema, etc.;
- With occurrences of:
task xxx timed outrecord not found (SELECT * FROM "plugin_declarations" WHERE plugin_unique_identifier = 'alipay/alipay_plugin:0.1.0@...')
Combined with ao_zhang’s description:
- The UI constantly displays “Installing Plugin”;
- Background task
Task timed out but not properly terminated;
- The same plugin (Tongyi / Alipay, etc.) has installation tasks repeatedly created.
This indicates:
- A certain installation task has timed out, but its status was not correctly marked as “finished,” causing the daemon process to continuously believe it’s still installing;
- Some plugins’
plugin_unique_identifier cannot be found in the DB (record not found), but the installation process continues to be scheduled, further messing up the state.
II. First, “Brake” – Stop the Daemon Process from Continuously Spawning Tasks
On your server, first stop the plugin daemon process container:
docker stop docker-plugin_daemon-1
Purpose:
- Immediately stop creating new installation tasks and stop continuously logging
Task timed out...;
- Facilitate subsequent cleanup (otherwise, new tasks will be spawned again right after cleaning).
Start it again after cleaning:
docker start docker-plugin_daemon-1
III. How to Obtain Authorization (Bearer Token) in a Local Deployment Environment
You are all using 1.11.4 docker-compose self-hosting. Even locally, the frontend will automatically carry a Bearer Token when accessing the backend, it’s just usually not visible.
Steps (using Chrome/Edge as an example):
- In your browser, access your Dify admin panel (e.g.,
http://SERVER_IP or http://localhost), and log in normally with an administrator account.
- Press
F12 to open developer tools → Switch to the “Network” panel.
- Click on any other menu item on the page (e.g., enter “Apps”, “Datasets”, etc.) to ensure an API request is sent.
- In the Network list, find a request with a path similar to
/console/api/... and click on it.
- In “Headers”, find:
Authorization: Bearer xxxxxxxx...
- Copy the long string of token after
Bearer (keep it for yourself, do not post it on the forum).
With this token, you can use curl on the server to call the cleanup API without needing “cloud-specific” Authorization.
IV. Cleaning Up “Stuck Installation Tasks”
In the previous post titled “After plugin installation fails, the UI always shows 1 plugin installing,” there is already a dedicated POST API endpoint and body template for “cleaning up installation task status.” You can follow the instructions there.
The general way to call it is as follows (replace the path and body with the actual content provided in that post):
curl -X POST "http://<YOUR_BACKEND_ADDRESS>/<API_PATH_FROM_THAT_POST>" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <TOKEN_COPIED_IN_PREVIOUS_STEP>" \
-d '{
... Fill in the JSON body from that post here ...
}'
Note:
<YOUR_BACKEND_ADDRESS>:
- If you started it directly using the official Docker directory, Nginx usually exposes both the frontend and backend on port 80. You can directly use
http://<SERVER_IP> or the address you currently use to access Dify;
- If you have a custom reverse proxy, please use the domain/port through which your frontend normally accesses Dify.
- For the path and request body, please follow exactly what was provided in that old post. Do not guess, to avoid accidentally deleting other plugins or task statuses.
After a successful call:
- Refresh the Dify page.
- The “Installing Plugin” prompt in the top right corner should disappear;
- The stuck plugin should change to “Not Installed” or a failed state.
V. If All Plugins Still Time Out After Cleanup, Which Direction Should You Troubleshoot?
You are all on 1.11.4, and:
- Local installation (uploading
difypkg) also times out;
- Marketplace installation also times out;
- Continuous
timeout and record not found in logs.
This usually indicates that it’s not an issue with a single plugin, but rather that the plugin runtime environment itself is abnormal. Several key areas:
1. Machine Performance and Docker Resources
Plugin installation involves creating a Python virtual environment and downloading dependencies within the plugin container. If the machine is “tight”:
- Insufficient CPU/memory;
- Too few resources allocated by Docker;
Both can cause tasks to run very slowly or even time out. Corresponding actions:
- Confirm the machine has at least:
- 2 CPU cores, 4GB+ RAM (official minimum recommendation suggests 8GB for more stability);
- In Docker Desktop (if on Mac/Win), appropriately increase CPU / Memory;
- On the server, use
top/htop to observe if CPU / MEM are maxed out during installation.
2. Is External Network / Python Source Access Smooth in the Plugin Container?
Based on other plugin posts, many installation failures in 1.11.x versions are due to:
- The default PyPI source being unreachable or very slow;
- Network policies or proxies blocking the plugin container from accessing the external network.
Troubleshooting:
- Enter the plugin daemon container:
docker exec -it docker-plugin_daemon-1 /bin/bash
- Inside the container, try:
ping pypi.org
curl -I https://pypi.org/simple
If it’s completely unreachable or has extremely high latency, installation will easily time out.
Consider:
- Setting a domestic Python source for plugins in
.env (if supported by the official version you are using);
- Or configuring a network proxy at the host level to ensure the container can access the external network normally.
3. What Does record not found Indicate?
In your logs, similar to:
SELECT * FROM "plugin_declarations" WHERE plugin_unique_identifier = 'alipay/alipay_plugin:0.1.0@...' ... record not found
This indicates:
- The plugin declaration was not successfully written to the database;
- But subsequent steps of the installation process are still querying based on this
plugin_unique_identifier and cannot find a record.
After you use the API to clean up installation tasks:
- It is recommended to reopen the plugin marketplace/plugin management page;
- To avoid accumulating old “dirty” states, first install only a simple plugin for testing (e.g., the built-in official demo plugin):
- If even the simple plugin times out, it’s an “environment-level issue”;
- If the simple plugin works, but certain specific plugins fail, then focus on the dependencies and network of those specific plugins.
VI. If API Cleanup Still Doesn’t Work, Only Two “Reset State” Paths Remain (High Risk)
Consider this only if you confirm data can be backed up and you have experience with database operations:
-
Full Stack Shutdown + Database Backup
docker compose down
Assuming the Postgres container is named docker-db_postgres-1, backup:
docker exec -t docker-db_postgres-1 \
pg_dump -U <db_user> <db_name> > dify_backup.sql
-
Enter the database and delete or change the status of plugin-related “installation tasks” and “installing states” to failed.
Table names/fields vary slightly across different versions for this step. It is not recommended to guess field names yourself, as it’s very easy to accidentally delete other things.
If you must take this path, it is recommended that you open a separate post or add here:
- Dify version and Postgres-related configuration in
docker-compose.yml;
- A screenshot of the plugin-related table names and structure using
\dt;
Then we can together deliberate on the specific SQL.
VII. Next Steps for Your Feedback to Facilitate Precise Localization
It is recommended that both of you add the following information to this post:
-
Execute:
docker logs docker-plugin_daemon-1 -n 200
Redact and paste the log segments containing Task timed out but not properly terminated and record not found.
-
Following the steps above to obtain Authorization: Bearer ..., attempt a POST call for “cleaning up installation tasks”:
- Which API path was used for the call?
- What was the returned HTTP status code (200 / 4xx / 5xx)?
- After the call, refresh the UI. Did the “Installing Plugin” prompt disappear?
-
After cleanup, try installing the simplest plugin again to see if it still consistently reports Task timed out but not properly terminated.
As long as we can confirm:
- The cleanup API can successfully “reset” stuck tasks;
- But new installations still time out;
Then we can basically conclude that it’s an “environment/network/resource” issue, rather than just a one-time dirty data problem. Afterwards, we can provide targeted guidance for environment optimization, or suggest considering an upgrade to a newer version (subsequent versions have indeed had continuous fixes for plugin installation timeouts and task cleanup).
Related Documentation
If it’s convenient for you, please first go through the three steps above: “brake + get token + call cleanup API,” then reply to this post with the execution results. We can then together narrow down the root cause to either an “environment issue or a version bug.”
Version Information
Key point
