Posted by an AI assistant on scottcain's behalf.
Summary
A gxformat2 step referencing a real, registered user-scoped dynamic tool by bare tool_id imports
and round-trips through gxwf convert without ever populating or requiring a tool_uuid. But real
Galaxy's step-to-tool resolution for a dynamic tool requires the native .ga step to carry that
tool's tool_uuid explicitly. A bare tool_id never resolves to a user-scoped dynamic tool, even
after successful registration and even though the tool_id string itself is correct.
The result: all 3 UDT steps showed "Tool is not installed" after a clean gxformat2 import, with no
schema-level signal of what was missing.
Evidence
gxformat2 import of the run's workflow — all 3 UDT tool_ids correct, all 3 tools already registered
via /api/unprivileged_tools — still showed all 3 steps tool-unresolved. Fetching the imported
workflow natively via GET /api/workflows/{id}/download confirmed each UDT step's JSON had no
tool_uuid key at all. Manually setting tool_uuid to each registered tool's real UUID in that
native JSON and re-importing via POST /api/workflows produced a workflow with zero step errors
on the same check.
Compounded by a second, separately-filed gxwf defect (step.in is not iterable), which blocked
using gxwf itself for the format2 → native conversion, forcing the round trip through Galaxy's own
download endpoint.
Expected
Either extend the gxformat2 step schema and galaxy-workflow-draft-format to model an optional
tool_uuid — populated once a dynamic/UDT tool is registered — so a draft can carry it through the
normal pipeline; or document explicitly in freeform-summary-to-galaxy-template,
advance-galaxy-draft-step, and run-workflow-test that a step resolving to a UDT must, at
deployment time, be converted to native .ga with its tool_uuid injected post-registration. Neither
is documented anywhere in the pipeline's packaged references today.
Posted by an AI assistant on scottcain's behalf.
Summary
A gxformat2 step referencing a real, registered user-scoped dynamic tool by bare
tool_idimportsand round-trips through
gxwf convertwithout ever populating or requiring atool_uuid. But realGalaxy's step-to-tool resolution for a dynamic tool requires the native
.gastep to carry thattool's
tool_uuidexplicitly. A baretool_idnever resolves to a user-scoped dynamic tool, evenafter successful registration and even though the
tool_idstring itself is correct.The result: all 3 UDT steps showed "Tool is not installed" after a clean gxformat2 import, with no
schema-level signal of what was missing.
Evidence
gxformat2 import of the run's workflow — all 3 UDT
tool_ids correct, all 3 tools already registeredvia
/api/unprivileged_tools— still showed all 3 steps tool-unresolved. Fetching the importedworkflow natively via
GET /api/workflows/{id}/downloadconfirmed each UDT step's JSON had notool_uuidkey at all. Manually settingtool_uuidto each registered tool's real UUID in thatnative JSON and re-importing via
POST /api/workflowsproduced a workflow with zero step errorson the same check.
Compounded by a second, separately-filed
gxwfdefect (step.in is not iterable), which blockedusing
gxwfitself for the format2 → native conversion, forcing the round trip through Galaxy's owndownload endpoint.
Expected
Either extend the gxformat2 step schema and
galaxy-workflow-draft-formatto model an optionaltool_uuid— populated once a dynamic/UDT tool is registered — so a draft can carry it through thenormal pipeline; or document explicitly in
freeform-summary-to-galaxy-template,advance-galaxy-draft-step, andrun-workflow-testthat a step resolving to a UDT must, atdeployment time, be converted to native
.gawith itstool_uuidinjected post-registration. Neitheris documented anywhere in the pipeline's packaged references today.