feat: add isolated Python module runtime - #3478
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
❌ 6 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
7b1680e to
e9c8f9b
Compare
e9c8f9b to
4379fd0
Compare
Greptile SummaryThis change adds an isolated Python runtime that executes module implementations from sibling projects while preserving host-side RPC, stream, and lifecycle interfaces. One reliability and denial-of-service issue remains: output from an isolated runtime is captured but never drained, so verbose logging can block the runtime before it processes later RPC or lifecycle work. The earlier report that isolated runtimes survive owner termination was disproved. A real ExampleExternal runtime exited within two seconds after its owner alone received SIGKILL, so the tested runtime did not remain orphaned. Confidence Score: 3/5The isolated Python runtime can deadlock after producing enough captured output, preventing applications from completing RPC and lifecycle operations. A verified denial-of-service failure remains in the isolated runtime subprocess handling. Files Needing Attention: dimos/core/isolated_python_module.py
|
4379fd0 to
8e4879a
Compare
8e4879a to
36b9b55
Compare
36b9b55 to
ab3408d
Compare
a5a137c to
4d8615e
Compare
4d8615e to
8280614
Compare
8280614 to
c4e9f2c
Compare
c4e9f2c to
36b9b55
Compare
Contribution path
Problem
dimOS needs to run Python modules with dependency sets that conflict with the host environment while preserving normal typed streams, RPCs, skills, module references, lifecycle management, and restart behavior.
Solution
IsolatedPythonModule, a host-side contract backed by a concrete subclass in a sibling Python project.How to Test
Validated on the #3465 base: 21 focused tests passed, targeted mypy passed, pre-commit passed, and the real subprocess example exited cleanly.
Checklist