tests/scripts/no_server_video_decode.test.mjs is the gate that keeps server-side video decoding from coming back. It scans source, Docker, CI and manifests for decoder names, and it now states its own limits in its docstring rather than implying it catches everything. This issue records those limits so they are visible outside the file.
What it cannot see:
- a name assembled at run time -
os.environ.get("VISIONSET_DECODER", "ff" + "mpeg") passed to subprocess.run. shutil.which is deliberately not banned: the repository uses it to find its own console script.
- a decoder nobody has listed yet - the ban is by name, so a library that has not been thought of passes.
- a call split over lines - the scan is line by line.
- a transitive decoder that does not name itself - a dependency that decodes internally without any banned string appearing.
It is a tripwire against the convenient reintroduction, not a sandbox. Closing any of these means a different mechanism - a dependency-graph check, or an import-time assertion in the distribution itself - rather than more patterns.
tests/scripts/no_server_video_decode.test.mjsis the gate that keeps server-side video decoding from coming back. It scans source, Docker, CI and manifests for decoder names, and it now states its own limits in its docstring rather than implying it catches everything. This issue records those limits so they are visible outside the file.What it cannot see:
os.environ.get("VISIONSET_DECODER", "ff" + "mpeg")passed tosubprocess.run.shutil.whichis deliberately not banned: the repository uses it to find its own console script.It is a tripwire against the convenient reintroduction, not a sandbox. Closing any of these means a different mechanism - a dependency-graph check, or an import-time assertion in the distribution itself - rather than more patterns.