dispatch/tool/invoke "HTTP/1.1 404 Not Found

[coderlsc]

Self Checks

To make sure we get to you in time, please check the following :)

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• "Please do not modify this template :) and fill in all the required fields."

Versions

1. dify-plugin-daemon 0.5.8-local
2. dify-api 1.13.3

Describe the bug
My plugin-daemon was originally at version 0.5.3-local and had an issue where plugins could not be installed, with the error reported at langgenius/dify#35125. Following the instructions in the issue, I upgraded the version to 0.5.5-local, which resolved the previous problem. However, this caused issues with certain plugins that use pytoml dependency declaration files and contain uvlock files.
To address this, I intended to use the new configuration parameters introduced in version 0.5.8-local, such as the environment variable PLUGIN_IGNORE_UV_LOCK=true, so I upgraded to 0.5.8. After startup, I found that Dify calls the plugin execution interface and reports the following error:
INFO [_client.py:1025] ec4ec5d198 HTTP Request: POST http://ip:port/plugin/tenant-id/dispatch/tool/invoke "HTTP/1.1 404 Not Found"

Expected behavior
correctly locate the plugin and execute it

Additional context
Add any other context about the problem here.

[dosubot]

Hi @coderlsc! I'm Dosu and I’m helping the dify-plugin-daemon team.

The 404 on /dispatch/tool/invoke is not caused by the route being removed — it still exists in 0.5.8-local alongside the newer /v2/invoke/dispatch routes [1]. The 404 most likely means the plugin runtime failed to register during startup, so the daemon can't find a running plugin to dispatch to.

Here are the most common causes and things to check:

1. Check plugin daemon logs for launch errors — look for "plugin runtime not found" or dependency installation failures at startup. If the plugin failed to install its dependencies (especially with the uv.lock/pyproject.toml changes), it won't register, and dispatch calls will 404.

2. Database migrations — starting from 0.5.6, migrations no longer run automatically on startup [2]. If you jumped from 0.5.3 → 0.5.8, you may need to run migrations manually.

3. Version configuration — since v0.5.2, the version config must exactly match the daemon version, or you'll get "plugin runtime not found" errors [3].

4. Storage configuration — verify PLUGIN_STORAGE_LOCAL_ROOT is properly configured and the plugin working directories are intact after the upgrade [3].

5. Full rebuild — try a complete docker-compose down and rebuild to ensure all components are properly synchronized.

Your PLUGIN_IGNORE_UV_LOCK=true config is correct for solving the uv.lock dependency issue, but it's unrelated to the 404 routing error itself. The 404 is a symptom of plugins not being successfully launched/registered in the daemon.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[coderlsc]

2026-04-22T09:29:29.686063884+08:00 INFO dify-plugin-daemon middleware.go:83 trace_id=4a93e944d60346dc6b6da0c556455428 tenant_id=ce711a99-ff95-4ba4-b861-bce695211d5f HTTP request method=GET path=/plugin/ce711a99-ff95-4ba4-b861-bce695211d5f/management/tool?provider=mineru&plugin_id=langgenius%2Fmineru status=200 latency_ms=12 client_ip=10.206.65.133
2026-04-22T09:29:29.787477997+08:00 WARN dify-plugin-daemon node.go:163 no plugin states found in redis hashed_plugin_id=87e091a531c63c4df8acac87e85a1a5ed992e25cbd13e4d9cb9a2ba3a92d45cb scan_pattern=*:87e091a531c63c4df8acac87e85a1a5ed992e25cbd13e4d9cb9a2ba3a92d45cb
2026-04-22T09:29:29.787538664+08:00 ERROR dify-plugin-daemon middleware.go:134 no plugin available nodes found plugin=langgenius/mineru:0.5.1@ccf545b476c0771707ea21122f9342ebe24d2a44ae040268665b41a9ca9f37fe
2026-04-22T09:29:29.787853795+08:00 ERROR dify-plugin-daemon factory.go:28 PluginDaemonInternalServerError error="no available node, plugin runtime not found" traceback="goroutine 612 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:26 +0x5e\ngithub.com/langgenius/dify-plugin-daemon/internal/types/exception.InternalServerError({0x3657840, 0xc0023874b0})\n\t/app/internal/types/exception/factory.go:27 +0x2f\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).redirectPluginInvokeByPluginIdentifier(0xc000465c00, 0xc001e5e100, {0xc001b3cb40, 0x58}, {0x3657840, 0x51331d0})\n\t/app/internal/server/middleware.go:137 +0x35c\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginDispatchGroup.(*App).RedirectPluginInvoke.func3(0xc001e5e100)\n\t/app/internal/server/middleware.go:109 +0x8c\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginDispatchGroup.(*App).FetchPluginInstallation.func2(0xc001e5e100)\n\t/app/internal/server/middleware.go:81 +0x22b\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginDispatchGroup.CollectActiveDispatchRequests.func1(0x3132ee8?)\n\t/app/internal/server/controllers/health_check.go:28 +0x25\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginGroup.CheckingKey.func1(0xc001e5e100)\n\t/app/internal/server/middleware.go:29 +0x95\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.PrometheusMiddleware.func8(0xc001e5e100)\n\t/app/internal/server/middleware.go:224 +0x71\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.CollectActiveRequests.func7(0xc0007ef6a8?)\n\t/app/internal/server/controllers/health_check.go:20 +0x25\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.LoggerMiddleware.LoggerMiddlewareWithConfig.func12(0xc001e5e100)\n\t/app/pkg/utils/log/middleware.go:64 +0xaa\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.TraceMiddleware.func5(0xc001e5e100)\n\t/app/pkg/utils/log/middleware.go:36 +0x1cb\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.RecoveryMiddleware.func4(0x7fef87e14ac8?)\n\t/app/pkg/utils/log/middleware.go:108 +0x3f\ngithub.com/gin-gonic/gin.(*Context).Next(0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192 +0x4e\ngithub.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc00079a000, 0xc001e5e100)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/gin.go:689 +0x435\ngithub.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc00079a000, {0x368bea0, 0xc003406960}, 0xc000383400)\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/gin.go:643 +0x1ad\nnet/http.serverHandler.ServeHTTP({0x367c638?}, {0x368bea0?, 0xc003406960?}, 0x6?)\n\t/usr/local/go/src/net/http/server.go:3340 +0x8e\nnet/http.(*conn).serve(0xc000994990, {0x3690df8, 0xc0007ce0f0})\n\t/usr/local/go/src/net/http/server.go:2109 +0x665\ncreated by net/http.(*Server).Serve in goroutine 150\n\t/usr/local/go/src/net/http/server.go:3493 +0x485\n"
github.com/langgenius/dify-plugin-daemon/internal/types/exception.InternalServerError
/app/internal/types/exception/factory.go:28
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).redirectPluginInvokeByPluginIdentifier
/app/internal/server/middleware.go:137
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginDispatchGroup.(*App).RedirectPluginInvoke.func3
/app/internal/server/middleware.go:109
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginDispatchGroup.(*App).FetchPluginInstallation.func2
/app/internal/server/middleware.go:81
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginDispatchGroup.CollectActiveDispatchRequests.func1
/app/internal/server/controllers/health_check.go:28
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginGroup.CheckingKey.func1
/app/internal/server/middleware.go:29
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.PrometheusMiddleware.func8
/app/internal/server/middleware.go:224
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.CollectActiveRequests.func7
/app/internal/server/controllers/health_check.go:20
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.LoggerMiddleware.LoggerMiddlewareWithConfig.func12
/app/pkg/utils/log/middleware.go:64
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.TraceMiddleware.func5
/app/pkg/utils/log/middleware.go:36
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/langgenius/dify-plugin-daemon/internal/server.(*App).server.RecoveryMiddleware.func4
/app/pkg/utils/log/middleware.go:108
github.com/gin-gonic/gin.(*Context).Next
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/context.go:192
github.com/gin-gonic/gin.(*Engine).handleHTTPRequest
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/gin.go:689
github.com/gin-gonic/gin.(*Engine).ServeHTTP
/go/pkg/mod/github.com/gin-gonic/gin@v1.11.0/gin.go:643
net/http.serverHandler.ServeHTTP
/usr/local/go/src/net/http/server.go:3340
net/http.(*conn).serve
/usr/local/go/src/net/http/server.go:2109

2026-04-22T09:29:29.78818165+08:00 WARN dify-plugin-daemon middleware.go:83 trace_id=6895aaeb0fcd1e19334694b6323e0dcc tenant_id=ce711a99-ff95-4ba4-b861-bce695211d5f HTTP request client_ip=10.206.65.134 method=POST path=/plugin/ce711a99-ff95-4ba4-b861-bce695211d5f/dispatch/tool/invoke status=404 latency_ms=83 @dosu

[dosubot]

Thanks for sharing the full logs — they clarify the issue. The 404 is not a missing route; it's a "plugin runtime not found" error. The key log line is:

WARN  node.go:163  no plugin states found in redis  hashed_plugin_id=87e091a5...  scan_pattern=*:87e091a5...

This means the daemon is trying to find a registered runtime for langgenius/mineru:0.5.1 in Redis, but no plugin state exists there. The plugin was found in the management API (status=200), so it's installed — it just hasn't successfully launched and registered its runtime.

A few things to check:

1. Are you running multiple daemon replicas/pods? In local mode (PLATFORM=local, which is the default for -local builds), plugin runtime state is stored in-memory per pod and is not synchronized via Redis [1]. If a request is routed to a pod that didn't launch the plugin, you'll get this exact error. Running a single replica is the most reliable fix for this [2].

2. Check if the plugin actually launched successfully. Look for earlier log messages around startup — any dependency installation failures (especially with the PLUGIN_IGNORE_UV_LOCK=true change) would prevent the plugin from registering its runtime. Search your logs for mineru around startup time to see if there are launch errors.

3. Database migrations. Since you jumped from 0.5.3 to 0.5.8, migrations no longer run automatically on startup (starting from 0.5.6). You may need to run them manually [3].

4. Try a full restart. Do a complete docker-compose down (or equivalent), clear any stale state, and bring everything back up to ensure the daemon re-registers all plugins from scratch.

The most common cause of this specific error pattern (management API returns 200, but dispatch returns 404) is the plugin failing to launch its runtime process — so checking the daemon logs around startup for the mineru plugin is the best first step.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[coderlsc]

1. I have confirmed that the deployed instance is not a multi-replica one; instead, there is only a single instance.
2. The startup logs of the plugin service show the entry "database migration completed successfully", which rules out the possibility that database migration was not executed. @dosu

[dosubot]

Thanks for confirming those. Since it's a single instance and migrations ran fine, the most likely cause is that the mineru plugin's runtime process failed to launch, so it never registered its state in Redis. The plugin shows as "installed" (management API returns 200), but the actual Python process either crashed during dependency installation or failed to start and send a heartbeat.

Even in single-instance local mode, the daemon still uses Redis to track plugin runtime state for dispatch [1]. Registration only happens after the plugin process successfully starts and sends its first heartbeat [2]. If that never happens, you get exactly this error.

Here's what I'd suggest:

1. Check daemon logs for mineru launch errors — look for messages around dependency installation (uv sync failures), context cancellation, or heartbeat timeouts. The plugin launch flow acquires a Redis lock, runs uv sync, starts the Python process, and waits up to 120 seconds for a heartbeat [3]. If any of those steps fail, the runtime won't register.

2. Try toggling PLUGIN_IGNORE_UV_LOCK — if you have it set to true, the daemon bypasses the frozen uv.lock and does a fresh dependency resolution [4]. This could cause resolution failures for certain plugins. Try setting it to false temporarily to see if mineru launches with its bundled lock file. You can also check if PIP_MIRROR_URL is correctly set and reachable.

3. Clean reinstall of the plugin — remove stale state and reinstall:

   • Delete the plugin installation record from the database
   • Clear the plugin's working directory under your storage path
   • Restart the daemon
   • Reinstall the plugin

4. Check configuration version — starting with v0.5.2, the daemon requires the configuration version to match exactly [5]. A mismatch can cause plugins to install but fail to launch silently.

The most actionable next step is sharing the daemon logs filtered for mineru — that will show exactly where the launch process is failing.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[fatelei]

1. I have confirmed that the deployed instance is not a multi-replica one; instead, there is only a single instance.
2. The startup logs of the plugin service show the entry "database migration completed successfully", which rules out the possibility that database migration was not executed. @dosu

try reinstall the plugin