Bonsai 2.9 made --export-image fail when a workflow contains unknown types. That detection was implemented in #2267 and resolved the original request in #1892. The way the failure is reported, and the decision to produce no image at all, can still be improved in a few ways raised in the follow-up discussion on #1892 and in #2298. This issue collects those improvements.
Current behavior
When the workflow contains unknown types, the command aborts with a single generic message, "The workflow contains unknown types. Please ensure any missing dependencies are installed before exporting the workflow," and writes no image. The message does not say which nodes are affected or which types failed to load.
This explicit failure is intentional and worth preserving. It keeps cross-hatched placeholder nodes out of generated documentation, which was the original motivation in #1892, and a nonzero exit code lets CI fail the build rather than publish a broken image.
Requested improvements
- Report every faulting node, not just a single generic message. A workflow with several missing dependencies currently gives no indication of how many or which.
- Include the full type name of each unknown type and the associated load error. This detail already exists per node; the proxy description on each
UnknownTypeBuilder reads "This is a proxy for the unknown type '{0}'. Please install any missing packages or replace this operator," but it is not included in the export error.
Open question: emitting the broken image
The reopened discussion also asked for the image to still be written on failure, so the broken render is available as an inspectable artifact. This is useful in CI, where artifacts are collected when a build fails and the cross-hatched nodes show at a glance which dependencies are missing, and for sharing a broken image deliberately in a bug report.
This conflicts with the rationale in #2267, that an image containing unknown types is invariably meaningless, which is why the current behavior produces nothing. The two can be reconciled if the command still returns a nonzero exit code whenever unknown types are present, so the build still fails and nothing is published automatically, while the image remains available for inspection. The decision to make here is whether to emit the image unconditionally, only behind an explicit flag, or not at all. Whatever is chosen, the failing exit code that the original use case in #1892 depends on must be preserved.
Related
- #2267 implemented the original detection and closed #1892.
- #2298 is an earlier write-up of this same follow-up, closed when the discussion moved to #1892.
- #2273 proposes validating or building workflows from the command line, a broader, related request to the diagnostics here.
- #1725 covers injecting metadata into placeholder types, which could enrich the per-node detail requested above.
Bonsai 2.9 made
--export-imagefail when a workflow contains unknown types. That detection was implemented in #2267 and resolved the original request in #1892. The way the failure is reported, and the decision to produce no image at all, can still be improved in a few ways raised in the follow-up discussion on #1892 and in #2298. This issue collects those improvements.Current behavior
When the workflow contains unknown types, the command aborts with a single generic message, "The workflow contains unknown types. Please ensure any missing dependencies are installed before exporting the workflow," and writes no image. The message does not say which nodes are affected or which types failed to load.
This explicit failure is intentional and worth preserving. It keeps cross-hatched placeholder nodes out of generated documentation, which was the original motivation in #1892, and a nonzero exit code lets CI fail the build rather than publish a broken image.
Requested improvements
UnknownTypeBuilderreads "This is a proxy for the unknown type '{0}'. Please install any missing packages or replace this operator," but it is not included in the export error.Open question: emitting the broken image
The reopened discussion also asked for the image to still be written on failure, so the broken render is available as an inspectable artifact. This is useful in CI, where artifacts are collected when a build fails and the cross-hatched nodes show at a glance which dependencies are missing, and for sharing a broken image deliberately in a bug report.
This conflicts with the rationale in #2267, that an image containing unknown types is invariably meaningless, which is why the current behavior produces nothing. The two can be reconciled if the command still returns a nonzero exit code whenever unknown types are present, so the build still fails and nothing is published automatically, while the image remains available for inspection. The decision to make here is whether to emit the image unconditionally, only behind an explicit flag, or not at all. Whatever is chosen, the failing exit code that the original use case in #1892 depends on must be preserved.
Related