Description
After rebuilding the bridge plugin's editor module on disk and fully restarting the editor (so the freshly built DLL is loaded from scratch), CLI invocations of the newly added tools still return 'Unknown tool: '. The DLL on disk has a current timestamp matching the rebuild, and the editor was confirmed restarted. The CLI argparse layer recognizes the tool names and routes them to the bridge, but the bridge reports them as not registered. This suggests either the new tools were not compiled into the shipped DLL (build silently dropped them), the registration call site was not updated, or the editor is somehow still loading a cached/old copy of the module from a different binaries directory. Either way, the user-visible failure mode is identical to the case where the editor was simply not restarted, with no diagnostic to help distinguish them.
Steps to Reproduce
- Add new bridge tools in plugin source (e.g. tools that inspect a particular asset type). 2) Build the bridge plugin's editor module successfully. 3) Confirm the editor module DLL on disk is the newly built one. 4) Fully exit the editor and relaunch. 5) Run the new tool via CLI.
Expected Behavior
Either the tool runs successfully, or the bridge returns a diagnostic indicating that the registry it loaded does not contain the tool and pointing at the loaded DLL path so the user can verify which binary is in memory.
Actual Behavior
Bridge returns plain 'Unknown tool: ' as if the tool never existed, with no information about which DLL/version is currently loaded. There is no way for the user to tell whether the editor failed to load the new DLL, the build silently omitted the tool, or registration was missed in code.
System Information
- CLI version: 1.25.4
- Python: 3.14.4
- OS: Windows-11-10.0.26200-SP0
- Bridge: reachable
Description
After rebuilding the bridge plugin's editor module on disk and fully restarting the editor (so the freshly built DLL is loaded from scratch), CLI invocations of the newly added tools still return 'Unknown tool: '. The DLL on disk has a current timestamp matching the rebuild, and the editor was confirmed restarted. The CLI argparse layer recognizes the tool names and routes them to the bridge, but the bridge reports them as not registered. This suggests either the new tools were not compiled into the shipped DLL (build silently dropped them), the registration call site was not updated, or the editor is somehow still loading a cached/old copy of the module from a different binaries directory. Either way, the user-visible failure mode is identical to the case where the editor was simply not restarted, with no diagnostic to help distinguish them.
Steps to Reproduce
Expected Behavior
Either the tool runs successfully, or the bridge returns a diagnostic indicating that the registry it loaded does not contain the tool and pointing at the loaded DLL path so the user can verify which binary is in memory.
Actual Behavior
Bridge returns plain 'Unknown tool: ' as if the tool never existed, with no information about which DLL/version is currently loaded. There is no way for the user to tell whether the editor failed to load the new DLL, the build silently omitted the tool, or registration was missed in code.
System Information