Backup-Verlauf-Log zeigt [object Object] (task.log liefert rohe {n,t}-Objekte) #19

New issue

Closed

opened 2026-06-01 19:18:55 +00:00 by chinux · 0 comments

chinux commented

2026-06-01 19:18:55 +00:00

Owner

Symptom

Backup-Verlauf → Log-Modal zeigt pro Zeile „[object Object]".

Root Cause (verifiziert, Stand Commit `b00c2ae0b1`)

Reine Form-Parität-Lücke — der #14-Commit hat log_tail gefixt, task.log aber übersehen:

Agent task.log → proxmox::get_task_log(upid) (Node-Agent/src/proxmox.rs:418) gibt das rohe pvesh-Array /nodes/X/tasks/UPID/log zurück, also [{"n":1,"t":"zeile"}, …] (Objekte!). Für leeren UPID sogar {"data":[]} (Objekt statt Array).
Backend task-log-Endpoint (server/routers/backup_router.py:164-178) reicht das 1:1 als {"lines": data} durch.
Frontend (NodeBackupPanel.svelte:751) rendert logModal.lines.join("\n") → join ruft toString() auf jedem {n,t}-Objekt → „[object Object]" pro Zeile.

Fix — `Node-Agent/src/proxmox.rs` `get_task_log`

Klartext-Zeilen zurückgeben statt der Objekte (nach n sortiert, t extrahiert):

pub fn get_task_log(upid: &str) -> Value {
    if upid.is_empty() { return json!([]); }   // leeres Array, nicht {"data":[]}
    let v = pvesh_get_json(&format!("/nodes/{}/tasks/{}/log", node_name(), upid));
    let lines: Vec<Value> = v.as_array().map(|arr| {
        let mut rows: Vec<(i64, String)> = arr.iter().filter_map(|e| {
            let t = e.get("t").and_then(|x| x.as_str())?.to_string();
            let n = e.get("n").and_then(|x| x.as_i64()).unwrap_or(0);
            Some((n, t))
        }).collect();
        rows.sort_by_key(|(n, _)| *n);
        rows.into_iter().map(|(_, t)| Value::String(t)).collect()
    }).unwrap_or_default();
    json!(lines)
}

Backend/Frontend bleiben unverändert (erwarten lines: string[]).

Akzeptanz

Log-Modal zeigt echte Task-Log-Zeilen.
cargo build/clippy grün.

Branch

fix/task-log-lines (oder zusammen mit #14-Nacharbeit)

## Symptom Backup-Verlauf → Log-Modal zeigt pro Zeile „[object Object]". ## Root Cause (verifiziert, Stand Commit `b00c2ae0b1`) Reine Form-Parität-Lücke — der #14-Commit hat `log_tail` gefixt, **`task.log` aber übersehen**: - Agent `task.log` → `proxmox::get_task_log(upid)` (`Node-Agent/src/proxmox.rs:418`) gibt das **rohe pvesh-Array** `/nodes/X/tasks/UPID/log` zurück, also `[{"n":1,"t":"zeile"}, …]` (Objekte!). Für leeren UPID sogar `{"data":[]}` (Objekt statt Array). - Backend `task-log`-Endpoint (`server/routers/backup_router.py:164-178`) reicht das 1:1 als `{"lines": data}` durch. - Frontend (`NodeBackupPanel.svelte:751`) rendert `logModal.lines.join("\n")` → `join` ruft `toString()` auf jedem `{n,t}`-Objekt → **„[object Object]"** pro Zeile. ## Fix — `Node-Agent/src/proxmox.rs` `get_task_log` Klartext-Zeilen zurückgeben statt der Objekte (nach `n` sortiert, `t` extrahiert): ```rust pub fn get_task_log(upid: &str) -> Value { if upid.is_empty() { return json!([]); } // leeres Array, nicht {"data":[]} let v = pvesh_get_json(&format!("/nodes/{}/tasks/{}/log", node_name(), upid)); let lines: Vec<Value> = v.as_array().map(|arr| { let mut rows: Vec<(i64, String)> = arr.iter().filter_map(|e| { let t = e.get("t").and_then(|x| x.as_str())?.to_string(); let n = e.get("n").and_then(|x| x.as_i64()).unwrap_or(0); Some((n, t)) }).collect(); rows.sort_by_key(|(n, _)| *n); rows.into_iter().map(|(_, t)| Value::String(t)).collect() }).unwrap_or_default(); json!(lines) } ``` Backend/Frontend bleiben unverändert (erwarten `lines: string[]`). ## Akzeptanz - Log-Modal zeigt echte Task-Log-Zeilen. - `cargo build`/`clippy` grün. ## Branch `fix/task-log-lines` (oder zusammen mit #14-Nacharbeit)

chinux changed title from ~~Backup-Verlauf Log [object Object]~~ to Backup-Verlauf-Log zeigt [object Object] (task.log liefert rohe {n,t}-Objekte)

2026-06-01 19:28:29 +00:00

chinux referenced this issue

2026-06-01 19:33:30 +00:00

Keine Backups sichtbar — get_storage_content nutzt ?content= statt pvesh --content #20

chinux referenced this issue from a commit

2026-06-01 19:58:37 +00:00

fix(node-agent): pvesh-shape bugs — guest-exec exited, storage content, task.log, log level (2.10.1)

chinux closed this issue

2026-06-01 19:59:28 +00:00