Can the Python wrapper spawn itself in a loop if SLING_HOME_DIR isn't accessible?

[dekinf]

Hi!
We had an incident and want to check a theory with you. We're not sure it's a bug.
Tanks in advance for any inputs here!

We ran this through the PyPI wrapper, as a user who can't access the SLING_HOME_DIR path (by mistake):

SLING_HOME_DIR=/home/other_user/.sling uv run sling conns exec MY_PG "SELECT 1"
It hung. Dozens of processes with the same command line appeared and filled the RAM until we killed them.

From reading sling/bin.py, our guess is:

1. The wrapper tries to create its cache dir under SLING_HOME_DIR (bin.py, get_binary_cache_dir) and gets a PermissionError.
2. It falls back to shutil.which('sling'). Under uv run, that returns the venv's sling launcher script, i.e. the Python wrapper itself, not the Go binary.
3. So the wrapper starts itself as a child process (same env), which fails the same way and starts another one, and so on. Each parent waits on its child, so the processes pile up.

Does that sound plausible? If so, a guard against the wrapper calling itself, or a clear error when the home dir can't be accessed, would help.

Sling 1.5.25 (PyPI, via uv), Ubuntu 24.04.

Thanks!

[davdifr]

Yes, that's exactly what happens. Tracing sling/bin.py and sling/__init__.py (unchanged since Nov 2025, so this applies to 1.5.25 and to the current 1.6.4):

1. At import time, if SLING_BINARY isn't set, bin.py calls download_binary(), which first calls get_binary_cache_dir(). That runs cache_dir.mkdir(parents=True, exist_ok=True) under SLING_HOME_DIR before the download's try block, so an inaccessible home raises PermissionError.
2. The module-level except Exception swallows it and falls back to shutil.which('sling'). Under uv run, the venv's bin/ comes first on PATH, so that's the sling console script, i.e. the wrapper itself.
3. cli() then runs [SLING_BIN, *args] through _exec_cmd, a with Popen(...) block that passes the same environment and waits for the child. The child imports the wrapper with the same SLING_HOME_DIR, fails the same way and starts another copy, so you get an unbounded chain of waiting processes.

I reproduced it end to end with sling 1.5.25 from PyPI in a venv (venv bin/ first on PATH, as with uv run) and a non-writable SLING_HOME_DIR, running your exact command under a process cap. The number of sling processes grew by about 16 per second (30 after 2 s) with nothing on stderr, until I killed the process group. With SLING_BINARY set, the same command didn't recurse at all.

Workarounds until it's fixed:

• Set SLING_BINARY to the Go binary. The wrapper then skips both the download and the PATH fallback (SLING_BIN = os.getenv("SLING_BINARY")).
• Or make sure SLING_HOME_DIR is accessible to the user running it, or unset it so it defaults to ~/.sling.

As for a fix: the fallback should probably ignore a which() result that is the wrapper's own launcher, and a PermissionError on SLING_HOME_DIR should fail with a clear message instead of falling through. That's worth an issue on sling-python, where the wrapper lives.

[dekinf]

Thanks for the detailed invest!

[flarco]

Fix has been pushed for next release: slingdata-io/sling-python@a555d14
Thanks @dekinf @davdifr

[dekinf]

Thanks!