Repository navigation
Code execution node exception. #40603
Description
Activity
@Zingway the 502 status code from the sandbox service typically has a few root causes. Here are the most common ones:
1. Verify the sandbox container is running and healthy
docker compose ps sandbox docker compose logs sandbox --tail=50
If the sandbox is crashing or restarting, the worker will get a 502 when it tries to reach
http://sandbox:8194/v1/sandbox/run[1].2. Check
python_pathin your sandbox configAfter upgrading, the Python binary path changed from
/usr/local/bin/python3to/opt/python/bin/python3. If yourdocker/volumes/sandbox/conf/config.yamlstill has the old path, code execution will fail [2]. Make sure it reads:python_path: /opt/python/bin/python3
Then restart the sandbox.
3. Sandbox seccomp issues (intermittent failures)
The
dify-sandbox:0.2.15image has a regression with an incomplete seccomp syscall whitelist, causing code executions to crash mid-response [3]. The sandbox returns HTTP 200 but then disconnects, and the worker surfaces this as the generic "network issue / sandbox not running" error [4]. A fix is tracked in dify-sandbox#275. As a workaround, you can downgrade tolanggenius/dify-sandbox:0.2.14[4].4. Ensure the sandbox is on the correct Docker network
The worker communicates with the sandbox at
http://sandbox:8194. If there's a network misconfiguration (e.g., services on different Docker networks), the worker can't reach the sandbox at all.Could you share the output of
docker compose psanddocker compose logs sandbox --tail=50? That would help narrow down whether the sandbox container is healthy, crashing, or unreachable.To reply, just mention @dosu.
Docs are dead. Just use Dosu.
-
This is an occasional issue.
-
The detailed error log of dify api is as follows:
ERROR [error_handler.py:101] Node 1773910518871 failed with ABORT strategy: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Failed to execute code, got status code 502, please check if the sandbox service is running )
ERROR [workflow_entry.py:116] 741ccd314f Unknown Error when workflow entry running
Traceback (most recent call last):
File "xx/dify-dev/api/core/workflow/workflow_entry.py", line 112, in run
yield from generator
File "xx/dify-dev/api/core/workflow/graph_engine/graph_engine.py", line 292, in run
raise self._graph_execution.error
RuntimeError: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Failed to execute code, got status code 502, please check if the sandbox service is running ) -
Please provide the smallest optimization measures.
-
@Zingway Since this is occasional (not constant) and produces a 502 from the sandbox, there are two likely root causes:
1. Sandbox seccomp whitelist gaps (most likely if using
dify-sandbox:0.2.15)The
dify-sandbox:0.2.15image has an incomplete seccomp syscall whitelist. When modern glibc/CPython hits a missing syscall, the sandbox child process is killed bySIGSYS("bad system call"), which surfaces as an intermittent failure at roughly a ~0.1% rate [1].The smallest fix: pin the sandbox image to
0.2.14in yourdocker-compose.yaml:sandbox: image: langgenius/dify-sandbox:0.2.14
This approach was confirmed to resolve the issue for other users with the same symptoms [2]. An upstream fix is in progress at dify-sandbox#275 [1].
2. Stale connections in the sandbox HTTP connection pool
The sandbox client uses a persistent connection pool with
keepalive_expiry=5.0seconds by default [3]. If the sandbox drops an idle connection, the pooled client may attempt to reuse a dead connection — resulting in an intermittent error. The error message in this case would typically say "Server disconnected without sending a response" rather than a 502 status code [2].You can reduce the keepalive expiry in your
.env:CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=2
To confirm which cause applies: check your sandbox container logs at the time of the failures. If you see
process finished with error: signal: bad system call (core dumped), it's the seccomp issue [1]. If the sandbox logs show no errors but the worker still gets a 502, it's likely a connection pool issue.To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
my version of dify-sandbox is 0.2.12
@Zingway Thanks for the version info. Since you're on
dify-sandbox:0.2.12, the seccomp whitelist regression that affects 0.2.15 doesn't apply to you [1].Without more detail on the specific issue you're hitting, here's what's most commonly reported with 0.2.12 — intermittent "Server disconnected without sending a response" errors. These point to stale connections in the worker's
httpxconnection pool [2]. The worker maintains persistent connections to the sandbox with a defaultkeepalive_expiryof 5 seconds [3] [4]. If the sandbox closes an idle connection before that window expires, the next request on it fails.If that matches your symptoms, you can try lowering or disabling the keepalive in your
.env:CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=2
or to disable keepalive entirely:
CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=0
Then restart your API and worker containers.
Could you share what error or behavior you're actually seeing? That will help narrow things down — for example, whether it's a connection issue, a sandbox crash, or something else entirely.
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
I checked the logs of the dify-sandbox container, and the following errors frequently appear. I'm not sure if they are related to the aforementioned issue:
2026/08/12 09:03:07 setup.go:146: [ERROR]failed to wait for the command to complete
2026/08/12 09:03:07 server.go:51: [PANIC]failed to install python dependencies: exit status 1@Zingway Yes, these errors are very likely directly related to the issues you're seeing. The log entry:
[PANIC] failed to install python dependencies: exit status 1means the sandbox is crashing when it tries to install Python dependencies. When this panic occurs, the sandbox restarts — and any in-flight or subsequent requests during that window will fail (e.g., 502 errors or "Server disconnected without sending a response") [1].
The most common causes for this error are:
-
The sandbox can't reach PyPI. Even if your code nodes don't explicitly import extra packages, the sandbox may try to install baseline dependencies on startup. If your environment has network restrictions or no internet access, pip will fail with exit status 1, triggering the panic.
-
The
/dependenciesvolume is misconfigured or missing. The sandbox expects the host path./volumes/sandbox/dependenciesto be mounted at/dependenciesinside the container. If this volume isn't mounted or thepython-requirements.txtthere is malformed, the installation fails [2].
Steps to diagnose:
-
Check the full pip error in sandbox logs:
docker logs <sandbox-container> 2>&1 | grep -A 20 "failed to install"
-
Verify your
docker/volumes/sandbox/dependencies/directory exists on the host and is mounted correctly. It can be empty if you don't need extra packages, but it must exist [2]. -
Test if the sandbox can reach PyPI:
docker exec <sandbox-container> pip install --dry-run requests
If your environment has no internet access, configure a pip mirror in
docker/volumes/sandbox/conf/config.yaml[2]:python_pip_mirror_url: "https://your-internal-pypi-mirror/simple"
Or set the
PIP_MIRROR_URLenvironment variable on the sandbox container (as shown in other users' docker-compose configurations) [1]. The panic and the downstream errors should both stop once pip can successfully complete.To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
-
According to the logs of the dify-sandbox, the following error is reported every two minutes:
2026/08/12 09:06:34 server.go:51: [PANIC]failed to install python dependencies: exit status 1
The python-requirements.txt file exists in the docker/volumes/sandbox/dependencies/ directory. Is it possible that the packages defined in the file trigger the pip installation, which in turn triggers the preceding error? The preceding error will restart the container. If the code execution node is running at this time, the problem mentioned at the beginning will occur.@Zingway Your analysis is correct — this is almost certainly the root cause of the intermittent failures. The flow is:
- The sandbox reads
python-requirements.txtfrom the mounted/dependenciesdirectory [1] - It tries to
pip installthe listed packages - pip fails (
exit status 1) — likely a network/connectivity issue reaching PyPI, or a package that can't be resolved - The sandbox panics and restarts
- Any code execution request in-flight at that moment fails with a "Server disconnected without sending a response" error [2]
To see the actual pip error, run the install manually inside the container:
docker exec -it <sandbox-container> pip install -r /dependencies/python-requirements.txt
This will show the real error being swallowed by the panic log.
Most likely fix — configure a pip mirror in
docker/volumes/sandbox/conf/config.yaml. The example config already has this field [3]:python_pip_mirror_url: https://pypi.tuna.tsinghua.edu.cn/simple
You can also set this via the
PIP_MIRROR_URLenvironment variable [1]. Replace it with a mirror accessible from your environment, or your internal PyPI mirror if you're in a restricted network.Alternative — if the packages in
python-requirements.txtare not strictly necessary, you can empty the file to stop the repeated install attempts and panics. The sandbox will still work for code nodes that only use the Python standard library.To reply, just mention @dosu.
Docs are dead. Just use Dosu.
- The sandbox reads
Self Checks
Dify version
1.11.2
Cloud or Self Hosted
Self Hosted (Source)
Steps to reproduce
Code execution node exception: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Failed to execute code, got status code 502, please check if the sandbox service is running )
✔️ Expected Behavior
Code execution node normal
❌ Actual Behavior
No response