Galaxy job errors aren't surfaced proactively in Orbit chat -- only when the user asks

[dannon]

A tool run that Galaxy immediately failed was not reported in the Orbit chat. From the user: "Galaxy UI immediately showed error but Orbit chatbox did not show error automatically. When I asked, then it could see there was an error."

What happens: galaxy_run_tool returns "Started tool ..." (HTTP 200 -- the job was submitted), and the agent treats that as success and moves on. The job then errors in Galaxy, but nothing polls the job to completion, so the failure is invisible until the user explicitly asks.

This is a trust problem -- a user watching only Orbit would believe the run succeeded. Expected: after submitting a job, surface terminal failures proactively (poll job/dataset state, or at least flag that submission != completion).

App 0.3.1, deepseek-v4-flash, trim_galore run. Overlaps the "don't claim completion before verifying artifacts" theme in #23 (this is the failure-surfacing flip side).

[nekrut]

Corroboration from a controlled 8-model experiment (opus, sonnet, gpt, gpt2, gemini-2.5-pro, gemini-3.5-flash, deepseek, haiku each reanalyzing the same C. auris RNA-seq dataset, 2026-06-02–04; evidence from per-run activity.jsonl).

Same class, with a concrete extra ask: when a job does fail, the stderr is never surfaced either.

• sonnet & opus: the fastp exit-255 failure returned invocationState: failed, jobSummary: {ok:0} with no stderr / error message, so the cause (the ConnectedValue empty-param bug, Workflow invocation mangles empty/optional parameters (ConnectedValue object stringified into the value) #186) was undiagnosable from Orbit — the human had to point it out.

Proactive surfacing should include the failed job's stderr, not just "it failed." Related: I filed #215 for the missing async-wait primitive that makes these failures even slower to notice.

[dannon]

One scoping note so this doesn't get mis-aimed at galaxy-mcp: galaxy_run_tool returning Started tool .../200 is correct -- the submission genuinely succeeded, the job only fails later. I checked, and galaxy-mcp raises real HTTP errors as isError=true, so there's no error-flag bug to fix on that side. The gap is entirely ours: nothing polls the submitted job to terminal state. This is really the failure-surfacing half of the same missing piece as #215 (async invocation-wait + reconcile) and #150 (job/step counts never populate) -- one wait/reconcile loop closes all three.

[dannon]

Beta tester (Orbit 0.3.1, gemini-2.5-pro) reports the in-progress counterpart of this: while a Galaxy job runs, Orbit narrates "the job is still running / I'll monitor it" but surfaces no intermediate state -- the user sees nothing until the green output appears, and asks for queued (grey) / running (orange) job states to be visible in Orbit. Same proactive-surfacing gap as the error case here. Activity log shows the agent busy-polling galaxy_get_dataset_details on one dataset id 6+ times in a loop and never calling get_job_details/get_invocations -- so the state data isn't even being read (ties into #150's completed_steps plumbing and #215's poll-loop anti-pattern). Worth surfacing live job/invocation state in chat or a status strip.

[dannon]

Another instance of single-job completion not being surfaced (sanitized): a user directed the agent to run one Galaxy job (image_learner, Gemini 3.1 Pro preview). The tool started successfully and the agent polled get_history_contents repeatedly, but never reported that the job completed. Matches the "single tool runs leave no invocation block for the poller" angle in the #249 rework -- the agent sees the history contents but doesn't proactively announce terminal state.

[dannon]

Another instance of this on Orbit 0.4.1 (gpt-5.5): the agent reran a Galaxy Image Learner job, polled it to running, then handed back with "Done ... Current rerun status: running" -- it never waited for the terminal state or reported the actual model/report/artifact outputs. The prior run had ended in error (exit_code 1), and that was only discovered when the agent manually polled /api/jobs/... -- not surfaced proactively, which is exactly this issue.

Worth noting for retest: this build (v0.4.1, tagged 06-11) predates the async-by-default poller (#281, merged 06-13) and its hardening (#293, merged 06-14), so it has no completion/terminal-state notification. Recommend re-checking once those ship in the next release. xref #23 (verify before claiming completion), #215 (async wait primitive).