diff options
| author | SulfurNitride <SulfurNitride@users.noreply.github.com> | 2026-05-16 13:45:57 -0500 |
|---|---|---|
| committer | SulfurNitride <SulfurNitride@users.noreply.github.com> | 2026-05-16 13:45:57 -0500 |
| commit | e403a7a9e1a71dde52fe21e1dd2215c0981a3fbc (patch) | |
| tree | a823560fdfa0da676ca3a23119fdb30fcb877393 /libs/script_extender_plugin_checker/src | |
| parent | f39c7e06d2465258371412c4adac48ba72fddbb9 (diff) | |
plugins: surface plugin name and Python exception on init failure
"plugin failed to initialize" with no name and no exception text is
the canonical first-line indicator for a Python plugin that didn't
register — but it tells the user nothing about *which* plugin or
*why*. Encountered while diagnosing a flaky first-launch failure
where a Python plugin's init() silently returned False on cold
boot and succeeded on the next run, plus a Ready or Not instance
that wouldn't open.
Wrap the IPlugin::init trampoline in pyplugins.h manually instead
of relying on PYBIND11_OVERRIDE_PURE so we can:
- log the plugin's name and the surrounding hint when init()
returns False (typically a plugin swallowing an exception in
its own try/except);
- catch pybind11::error_already_set and log the Python exception
text + traceback before returning False to the C++ caller.
plugincontainer.cpp's "plugin failed to initialize" line now also
prints the plugin name so the proxied-candidate context is clear.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Diffstat (limited to 'libs/script_extender_plugin_checker/src')
0 files changed, 0 insertions, 0 deletions
