Aufgabenliste: 3. Tab "Geplante Jobs" mit vollem Lauf-Verlauf (neue scheduled_job_run-Tabelle, inkl. Auto-Update) #178

Closed
opened 2026-06-26 10:57:35 +00:00 by chinux · 0 comments
Owner

Ziel

In der Aufgabenliste (TaskDock.svelte, aktuell Tabs "Aktuell" + "Alle Nodes (Verlauf)") einen dritten Tab "Geplante Jobs" ergaenzen, der den vollen Verlauf der geplanten Scheduler-Jobs zeigt — also jeden einzelnen Lauf eines Crontab-/Command-Jobs auf VM oder Node, plus die Auto-Update-Laeufe (#174).

Problem / Ist-Zustand

  • ScheduledJob (server/models/scheduled_job.py) speichert nur den letzten Lauf: last_run_at, last_status, last_output. Keine Run-Historie, kein /runs-Endpoint.
  • schedule_router.py hat nur /jobs, /jobs/{id}, /jobs/{id}/run, /job-types — keine Verlaufs-Liste.
  • Auto-Update-Laeufe (#174) laufen ueber launch_bulk_job, ihr Ergebnis landet in node_auto_update.last_summary (auch nur letzter Lauf).
    → Fuer "jeder Lauf eine Zeile" fehlt die Datenquelle. Muss mit angelegt werden.

Backend — neue Tabelle scheduled_job_run (1 Zeile pro Lauf) + Migration

Head ist aktuell 0022_auto_update_dist → neue Migration 0023_scheduled_job_run.
Felder:

  • id (UUID PK)
  • job_id (FK → scheduled_jobs.id, nullable — Auto-Update hat keinen ScheduledJob)
  • source enum: scheduler | auto_update (Herkunft, fuer Filter/Badge)
  • job_type (z. B. command.run, backup, vm.auto_update)
  • name (Job-Name bzw. "Auto-Update ")
  • node_name, vmid (nullable)
  • started_at, finished_at
  • status enum: ok | error | running | cancelled
  • output (Text, gekuerzt z. B. 4k)
  • summary (JSONB, optional — bei Auto-Update: ok/fail/reboot_required-Counts)
  • Index auf (started_at desc) + node_name.

Schreibstellen (History-Insert)

  1. Scheduler (scheduler.py ~Z.95-100): wo aktuell last_run_at/last_status/last_output gesetzt werden, zusaetzlich eine ScheduledJobRun-Zeile inserten (source=scheduler). last_* am Job bleibt fuer die Schnellanzeige erhalten.
  2. Auto-Update (update_router.launch_bulk_job Abschluss bzw. auto_update_router.run_auto_update_for_node): pro Lauf eine ScheduledJobRun (source=auto_update, summary=ok/fail/reboot_required).

Neuer Endpoint

  • GET /api/schedule/runs?limit=&node_name=&source= → letzte N Laeufe, mandanten-gescoped (require_read + list_user_accessible_nodes, Scope-WHERE vor LIMIT — Muster aus #108). Default sinnvoll begrenzt (z. B. 100).
  • Optional Retention: alte Runs > X Tage per Housekeeping kuerzen (kann Folge-Issue sein).

Frontend — 3. Tab im TaskDock

  • TaskDock.svelte: dritter Tab "Geplante Jobs" neben current/all (Z.183-185). Beim Aktivieren loadJobRuns().
  • Tabelle: Zeit (started_at), Job-Name, Typ, Node/VMID, Status-Badge (ok/error/running/cancelled), Herkunft-Badge (Scheduler/Auto-Update), Output-Peek (Klick → Detail/Tooltip wie bei den anderen Tabs).
  • Konsistent zum bestehenden Tab-Stil (td-tab, td-table), keine neue Optik erfinden.
  • Store-Anbindung analog loadAllTasks in lib/stores/tasks.svelte.ts.

Akzeptanz

  • TaskDock hat 3 Tabs; "Geplante Jobs" zeigt jeden Lauf als eigene Zeile (nicht nur den letzten).
  • Geplante Command/Crontab-Jobs (scheduler) und Auto-Update-Laeufe (#174) erscheinen, per Herkunft unterscheidbar.
  • Jeder neue Lauf erzeugt genau eine scheduled_job_run-Zeile; ScheduledJob.last_* bleibt fuer Schnellanzeige.
  • Liste ist mandanten-gescoped (kein Cross-Tenant), Scope-WHERE vor LIMIT.
  • Migration konsistent (1 Head: 0023 auf 0022).

Bezug

#174 (Auto-Update-Laeufe als Quelle), Scheduler (scheduler.py/schedule_router.py), #108 (Scope-Muster fuer den neuen Endpoint), Task-Center (TaskDock.svelte, tasks.svelte.ts).

Branch

feat/scheduled-job-run-history

## Ziel In der Aufgabenliste (`TaskDock.svelte`, aktuell Tabs **"Aktuell"** + **"Alle Nodes (Verlauf)"**) einen **dritten Tab "Geplante Jobs"** ergaenzen, der den **vollen Verlauf** der geplanten Scheduler-Jobs zeigt — also jeden einzelnen Lauf eines Crontab-/Command-Jobs auf VM oder Node, plus die **Auto-Update-Laeufe** (#174). ## Problem / Ist-Zustand - `ScheduledJob` (`server/models/scheduled_job.py`) speichert nur den **letzten** Lauf: `last_run_at`, `last_status`, `last_output`. **Keine Run-Historie**, kein `/runs`-Endpoint. - `schedule_router.py` hat nur `/jobs`, `/jobs/{id}`, `/jobs/{id}/run`, `/job-types` — keine Verlaufs-Liste. - Auto-Update-Laeufe (#174) laufen ueber `launch_bulk_job`, ihr Ergebnis landet in `node_auto_update.last_summary` (auch nur letzter Lauf). → Fuer "jeder Lauf eine Zeile" fehlt die Datenquelle. Muss mit angelegt werden. ## Backend — neue Tabelle `scheduled_job_run` (1 Zeile pro Lauf) + Migration Head ist aktuell `0022_auto_update_dist` → neue Migration `0023_scheduled_job_run`. Felder: - `id` (UUID PK) - `job_id` (FK → scheduled_jobs.id, nullable — Auto-Update hat keinen ScheduledJob) - `source` enum: `scheduler` | `auto_update` (Herkunft, fuer Filter/Badge) - `job_type` (z. B. `command.run`, `backup`, `vm.auto_update`) - `name` (Job-Name bzw. "Auto-Update <node>") - `node_name`, `vmid` (nullable) - `started_at`, `finished_at` - `status` enum: `ok` | `error` | `running` | `cancelled` - `output` (Text, gekuerzt z. B. 4k) - `summary` (JSONB, optional — bei Auto-Update: ok/fail/reboot_required-Counts) - Index auf `(started_at desc)` + `node_name`. ### Schreibstellen (History-Insert) 1. **Scheduler** (`scheduler.py` ~Z.95-100): wo aktuell `last_run_at/last_status/last_output` gesetzt werden, **zusaetzlich** eine `ScheduledJobRun`-Zeile inserten (source=`scheduler`). `last_*` am Job bleibt fuer die Schnellanzeige erhalten. 2. **Auto-Update** (`update_router.launch_bulk_job` Abschluss bzw. `auto_update_router.run_auto_update_for_node`): pro Lauf eine `ScheduledJobRun` (source=`auto_update`, summary=ok/fail/reboot_required). ### Neuer Endpoint - `GET /api/schedule/runs?limit=&node_name=&source=` → letzte N Laeufe, **mandanten-gescoped** (`require_read` + `list_user_accessible_nodes`, Scope-WHERE vor LIMIT — Muster aus #108). Default sinnvoll begrenzt (z. B. 100). - Optional Retention: alte Runs > X Tage per Housekeeping kuerzen (kann Folge-Issue sein). ## Frontend — 3. Tab im TaskDock - `TaskDock.svelte`: dritter Tab **"Geplante Jobs"** neben current/all (Z.183-185). Beim Aktivieren `loadJobRuns()`. - Tabelle: Zeit (started_at), Job-Name, Typ, Node/VMID, Status-Badge (ok/error/running/cancelled), Herkunft-Badge (Scheduler/Auto-Update), Output-Peek (Klick → Detail/Tooltip wie bei den anderen Tabs). - Konsistent zum bestehenden Tab-Stil (`td-tab`, `td-table`), keine neue Optik erfinden. - Store-Anbindung analog `loadAllTasks` in `lib/stores/tasks.svelte.ts`. ## Akzeptanz - TaskDock hat 3 Tabs; "Geplante Jobs" zeigt **jeden** Lauf als eigene Zeile (nicht nur den letzten). - Geplante Command/Crontab-Jobs (scheduler) **und** Auto-Update-Laeufe (#174) erscheinen, per Herkunft unterscheidbar. - Jeder neue Lauf erzeugt genau eine `scheduled_job_run`-Zeile; `ScheduledJob.last_*` bleibt fuer Schnellanzeige. - Liste ist mandanten-gescoped (kein Cross-Tenant), Scope-WHERE vor LIMIT. - Migration konsistent (1 Head: 0023 auf 0022). ## Bezug #174 (Auto-Update-Laeufe als Quelle), Scheduler (`scheduler.py`/`schedule_router.py`), #108 (Scope-Muster fuer den neuen Endpoint), Task-Center (`TaskDock.svelte`, `tasks.svelte.ts`). ## Branch `feat/scheduled-job-run-history`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chinux/theProx#178
No description provided.