Posted by Claude (AI assistant) on behalf of @jmchilton — they did not author this text personally.

planemo run --no_wait <tool.xml> <job.yml> submits the job and then crashes with an UnboundLocalError. The workflow path is fine; this is tool-only, and it has never worked.

Cause

In planemo/galaxy/activity.py::_execute, run_response = None is set at line 266. The tool branch (line 274) assigns response_kwds only inside if not kwds.get("no_wait"): (lines 289-307) and never assigns run_response. So with --no_wait the function falls through to line 338 if not run_response: and then line 347:

  File "planemo/galaxy/activity.py", line 347, in _execute
    **response_kwds,
      ^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'response_kwds' where it is not associated with a value

The workflow branch assigns run_response via invocation_to_run_response, so it never reaches that line.

Reachable from the CLI

--no_wait comes from no_wait_option() (planemo/options.py:1826) via engine_options() (options.py:1727), applied by cmd_run.py:37 and cmd_test.py. Nothing in cmd_run.py or planemo/engine/ guards it by runnable type, and GalaxyEngine.handled_runnable_types includes galaxy_tool/cwl_tool.

End-to-end, with only the Galaxy server mocked:

$ planemo run --no_wait project_templates/demo/cat.xml job.yml
Failed to execute Galaxy activity, throwing ErrorRunResponse
Run failed [Run failed with message [cannot access local variable 'response_kwds' where it is not associated with a value]]

Exit code 1. Same for the external engine (--galaxy_url ... --no_wait <tool>) and planemo test --no_wait <tool.xml>.

Provenance

Introduced by 15b4126 ("add --no_wait flag to run subcommand", 2021-04-27), which wrapped the tool-branch body in if not kwds.get('no_wait'): and pulled response_kwds under the guard - while the workflow branch in the same commit assigns it unconditionally. The tool path has been broken since the flag was added. The only test exercising --no_wait (tests/test_external_galaxy_commands.py:95) uses a workflow.

Impact

The tool job is submitted to Galaxy before the crash, so the user sees "Run failed" and a non-zero exit for a job that is in fact running - bad for scripted use.

Suggested fix

Mirror how the workflow path degrades under no_wait. Add an else to the guard at activity.py:289:

        else:
            response_kwds = {
                "job_info": None,
                "api_run_response": tool_run_response,
            }

GalaxyToolRunResponse.__init__ already takes job_info, and GalaxyBaseRunResponse defaults successful=True, so cmd_run then prints "Run successfully executed - exiting without waiting for results." as it does for workflows. The harness in tests/test_galaxy_activity.py is a line away from covering this.

Adjacent bug found while investigating

cmd_run.py:84 calls run_result.structured_data() on the ErrorRunResponse, and planemo/runnable.py:647 does assert isinstance(self, SuccessfulRunResponse). So any failed planemo run ends in an uncaught AssertionError after the "Run failed" message instead of exiting cleanly. That is independent of --no_wait and probably deserves its own fix.