Symptom: script output from automation run_script actions is not visible anywhere in the product. Surfaced by a user in discussion #2598 comparing against another RMM that shows the latest run's stdout inline next to the automation.
It is not just unrendered — the output is dropped server-side.
- Manual runs (
POST /scripts/:id/execute) write a script_executions row, and handleScriptResult (apps/api/src/routes/agentWs.ts:414-469) fills in stdout when the agent result arrives. Execution history and the device script-history tab render that.
- Automation
run_script actions never create an execution row. executeRunScriptAction (apps/api/src/services/automationRuntime.ts:868-873) queues the command with a synthetic executionId of ${runId}:${deviceId}:${actionIndex} — not a UUID. When the result comes back, handleScriptResult matches it against script_executions.id, a uuid column (apps/api/src/db/schema/scripts.ts:112-128); the update throws and lands in a caught, console-logged error (agentWs.ts:466-468). The real stdout is discarded.
automation_run_device_results.output (apps/api/src/db/schema/automations.ts:72-89) was clearly meant for this but only ever receives the automation's own log lines ("[info] Queued run_script action" — automationRuntime.ts:1750-1820), never the script's output.- Even that field is unrendered:
AutomationRunHistory.tsx:30 declares output?: string but the expanded panel shows only result.error.
Fix shape: persist the script's real stdout for automation-triggered runs (either mint a genuine script_executions row per device-action and correlate on it, or route the result into automation_run_device_results.output), then render it in the run-history expanded panel.
Related, distinct: #2698 (script stdout → custom fields), discussion #2598 (run-on-onboarding trigger). Note the synthetic id also means these results are invisible to the HTTP-path fix discussed in #3097 — whatever shared handler registry comes out of that should handle this correlation too.
Symptom: script output from automation
run_scriptactions is not visible anywhere in the product. Surfaced by a user in discussion #2598 comparing against another RMM that shows the latest run's stdout inline next to the automation.It is not just unrendered — the output is dropped server-side.
POST /scripts/:id/execute) write ascript_executionsrow, andhandleScriptResult(apps/api/src/routes/agentWs.ts:414-469) fills instdoutwhen the agent result arrives. Execution history and the device script-history tab render that.run_scriptactions never create an execution row.executeRunScriptAction(apps/api/src/services/automationRuntime.ts:868-873) queues the command with a syntheticexecutionIdof${runId}:${deviceId}:${actionIndex}— not a UUID. When the result comes back,handleScriptResultmatches it againstscript_executions.id, auuidcolumn (apps/api/src/db/schema/scripts.ts:112-128); the update throws and lands in a caught, console-logged error (agentWs.ts:466-468). The real stdout is discarded.automation_run_device_results.output(apps/api/src/db/schema/automations.ts:72-89) was clearly meant for this but only ever receives the automation's own log lines ("[info] Queued run_script action"—automationRuntime.ts:1750-1820), never the script's output.AutomationRunHistory.tsx:30declaresoutput?: stringbut the expanded panel shows onlyresult.error.Fix shape: persist the script's real stdout for automation-triggered runs (either mint a genuine
script_executionsrow per device-action and correlate on it, or route the result intoautomation_run_device_results.output), then render it in the run-history expanded panel.Related, distinct: #2698 (script stdout → custom fields), discussion #2598 (run-on-onboarding trigger). Note the synthetic id also means these results are invisible to the HTTP-path fix discussed in #3097 — whatever shared handler registry comes out of that should handle this correlation too.