Summary
Currently job output is only sent to the agent in a single call when the job finishes (POST /execution/finish). Long-running jobs show no output in the UI until they complete, making it impossible to monitor progress or diagnose hung jobs in real time.
Proposed Behaviour
While a job is running, the wrapper periodically sends accumulated output to the agent. The UI displays the latest partial output when viewing a running job, updating automatically via polling.
Affected Component
First Implementation Idea
- New agent endpoint —
POST /execution/{id}/progress accepts a output field and appends it to the stored output for the active execution (or replaces it — TBD based on memory constraints).
- cron-wrapper.sh — run the job command with output redirected to a temp file; a background loop reads the file and POSTs its current content to
/execution/{id}/progress every N seconds (configurable, default 10 s). The loop is killed after the job finishes and the final output is sent as usual via /execution/finish.
- Agent DB — partial output is written to the existing
output column on the in-progress execution row; no schema change required.
- Web UI — when a job status is "running", the output panel polls the history/detail endpoint every N seconds and refreshes the displayed output.
- Safety — output size cap (configurable) to prevent runaway jobs from flooding the DB; partial output is clearly labelled "(in progress)" in the UI.
Summary
Currently job output is only sent to the agent in a single call when the job finishes (
POST /execution/finish). Long-running jobs show no output in the UI until they complete, making it impossible to monitor progress or diagnose hung jobs in real time.Proposed Behaviour
While a job is running, the wrapper periodically sends accumulated output to the agent. The UI displays the latest partial output when viewing a running job, updating automatically via polling.
Affected Component
First Implementation Idea
POST /execution/{id}/progressaccepts aoutputfield and appends it to the stored output for the active execution (or replaces it — TBD based on memory constraints)./execution/{id}/progressevery N seconds (configurable, default 10 s). The loop is killed after the job finishes and the final output is sent as usual via/execution/finish.outputcolumn on the in-progress execution row; no schema change required.