feat(web): pickle-safe dynamic relay bridge classes - #3569
Conversation
- make_relay_bridge_class(specs) builds RelayBridgeModule subclasses at runtime. A spec is (stream, message type, direction), nothing else. - DimOS ships module classes through pickle (forkserver deploy, Actor.__reduce__). A runtime-built class cannot pickle by reference. - So the classes get a dedicated metaclass registered with copyreg: pickle serializes the port specs and rebuilds the class through the factory. - The factory is memoized process-wide so repeated unpickles return the identical class object (blueprints compare classes with `is`). - The reducer ships plain field tuples, not spec instances, so a class from a reloaded module still repickles cleanly. - Spec validation rejects reserved or invalid stream ids and names that collide with existing RelayBridgeModule attributes. - Pure addition (dynamic.py + tests). The channel authoring ticket on top of this compiles cockpit(channels=...) into such a class.
Greptile SummaryThis change introduces deterministic, memoized dynamic RelayBridgeModule classes with validation and pickle support so stream annotations can be reconstructed across process boundaries. The reload coverage and fresh-worker deployment coverage currently exercise separate flows. The restart path reloads the generated class before deploying it to a fresh Python worker, but no test covers those operations together. T-Rex validation blockedThe focused reload-then-clean-worker check could not execute because the Confidence Score: 4/5The implementation has focused coverage for reload serialization and fresh-worker deployment, but the production sequence combining both remains untested. The reported issue is limited to test coverage and does not demonstrate a current user-visible failure. Code inspection identifies the uncovered handoff between module reload and worker deployment. Files Needing Attention:
What T-Rex did
Reviews (1): Last reviewed commit: "feat(web): pickle-safe dynamic relay bri..." | Re-trigger Greptile |
| assert pickle.loads(data) is C, "pre-reload pickle lost identity" | ||
| assert pickle.loads(pickle.dumps(C)) is C, "re-pickle after reload failed" | ||
| again = mod.make_relay_bridge_class([mod.DynamicPortSpec("reload_feed", Vector3, "rx")]) | ||
| assert again is C, "factory lost identity after reload" |
There was a problem hiding this comment.
Reload-to-worker path remains untested
The reload test re-pickles the surviving generated class only in the interpreter where it remains published, while the fresh-worker test does not reload first. This leaves the coordinator's combined reload-plus-clean-worker deployment sequence untested, allowing a regression at that serialization boundary to pass the suite.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
❌ 1 Tests Failed:
View the top 1 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
No description provided.