mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-09-24 16:30:27 +08:00
mvdbeek
838c8ac856
``Registry.load_datatype_converters`` (``lib/galaxy/datatypes/registry.py:674``) walks the converter list from ``datatypes_conf.xml`` after boot and calls ``toolbox.load_tool(config_path)`` per entry. Under strict ``LazyToolBox.create_tool`` every converter raised ``RuntimeError`` (caught + logged by the registry as ``Error loading converter (…)``) and the ``datatype_converters`` dict stayed silently empty — so format-mismatch conversions via ``Dataset.find_conversion_destination`` were no-ops. Fix: in ``discover_tools()``, after the hidden-lib block, query ``galaxy.model._get_datatypes_registry()`` and yield a ``DiscoveredTool`` for each converter the registry has parsed. Same source of truth ``load_datatype_converters`` iterates, so we can't drift — what the registry will try to load is exactly what the populator indexes. The registry is populated by ``set_datatypes_registry()`` at app boot (``app/__init__.py:853``) before the toolbox initialises and inside ``populate_store(config_file=…)`` before ``populate_store_inline`` runs — both paths produce a live registry by the time the populator walks. On the (atypical) case where the registry isn't set, the try/except falls through and the converters remain unindexed; the eager ``load_datatype_converters`` then continues to catch + log the ``Error loading converter`` messages, matching today's pre-refactor behaviour. After this commit, ``Persisted ToolIndex for store __default__`` reports 580 entries (up from 564 = +16 converters that ``sample_tool_conf.xml`` doesn't list) and zero ``Error loading converter`` messages appear in the integration log. 16/16 integration tests + 113/113 unit tests still pass.