Manual forget via API fails instantly: "command.run carried no forget_groups (server didn't populate them)" #36

New Issue

2026-08-22T09:31:29+01:00

bobby commented

2026-08-22 09:31:29 +01:00

Summary

Triggering a forget job through the HTTP API fails immediately, before restic is invoked. The scheduled forget path works (the agent logs accepting forget job ... groups:1), so this is specific to the manual/run-now dispatch path: the server does not populate forget_groups on the command.run message.

This makes --dry-run forget unusable, which is exactly the tool you want when diagnosing a retention problem non-destructively.

Reproduce

curl -sk -b cookies.txt -X POST -H 'Content-Type: application/json' \
  -d '{"kind":"forget","args":["--dry-run"]}' \
  https://restic-manager.example.internal/api/hosts/<host_id>/jobs
# -> {"job_id":"01M0M8WN0MBFMT0DWZWV1W4Q9H","status":"queued"}

Observed

Job transitions to failed with identical start/finish timestamps and zero log lines:

# job 01M0M8WN0MBFMT0DWZWV1W4Q9H · kind forget · status failed
# started  2026-08-22T08:20:11.443Z
# finished 2026-08-22T08:20:11.443Z
# 0 log lines

Agent-side (host-A, agent v1.1.0):

{"time":"2026-08-22T08:20:11.446813855Z","level":"WARN","msg":"ws agent: handler returned error","type":"command.run","err":"forget: command.run carried no forget_groups (server didn't populate them)"}

Expected

The manual dispatch path should populate forget_groups from the host's source-group retention policy, the same way the scheduler does — so a run-now forget (with or without --dry-run) behaves identically to the scheduled one.

Evidence this is manual-path-only

On the same host, over 30 days of agent logs:

forget_groups error: 1 occurrence (the manual call above)
Scheduled forgets: log "msg":"agent: accepting forget job","groups":1 daily, e.g. 01M0KT1YZX54NRB9FDM7XPT0Z1 at 04:00:56 on 2026-08-22

Impact

Medium. Scheduled retention is unaffected, but there is no non-destructive way to inspect what a forget would do. Diagnosing a retention issue currently requires running a live, irreversible forget.

Environment

Agent v1.1.0 (commit 0f5110f3d9b91b269684453e6b8d14dbcffb93c6, built 2026-06-16T06:32:52Z)
restic 0.18.1, protocol_version 1
Reproduced on host host-A (Ubuntu 24.04)

## Summary Triggering a **forget** job through the HTTP API fails immediately, before restic is invoked. The scheduled forget path works (the agent logs `accepting forget job ... groups:1`), so this is specific to the manual/run-now dispatch path: the server does not populate `forget_groups` on the `command.run` message. This makes `--dry-run` forget unusable, which is exactly the tool you want when diagnosing a retention problem non-destructively. ## Reproduce ```bash curl -sk -b cookies.txt -X POST -H 'Content-Type: application/json' \ -d '{"kind":"forget","args":["--dry-run"]}' \ https://restic-manager.example.internal/api/hosts/<host_id>/jobs # -> {"job_id":"01M0M8WN0MBFMT0DWZWV1W4Q9H","status":"queued"} ``` ## Observed Job transitions to `failed` with identical start/finish timestamps and **zero log lines**: ``` # job 01M0M8WN0MBFMT0DWZWV1W4Q9H · kind forget · status failed # started 2026-08-22T08:20:11.443Z # finished 2026-08-22T08:20:11.443Z # 0 log lines ``` Agent-side (host-A, agent v1.1.0): ```json {"time":"2026-08-22T08:20:11.446813855Z","level":"WARN","msg":"ws agent: handler returned error","type":"command.run","err":"forget: command.run carried no forget_groups (server didn't populate them)"} ``` ## Expected The manual dispatch path should populate `forget_groups` from the host's source-group retention policy, the same way the scheduler does — so a run-now forget (with or without `--dry-run`) behaves identically to the scheduled one. ## Evidence this is manual-path-only On the same host, over 30 days of agent logs: - `forget_groups` error: **1 occurrence** (the manual call above) - Scheduled forgets: log `"msg":"agent: accepting forget job","groups":1` **daily**, e.g. `01M0KT1YZX54NRB9FDM7XPT0Z1` at 04:00:56 on 2026-08-22 ## Impact Medium. Scheduled retention is unaffected, but there is no non-destructive way to inspect what a forget *would* do. Diagnosing a retention issue currently requires running a live, irreversible forget. ## Environment - Agent `v1.1.0` (commit `0f5110f3d9b91b269684453e6b8d14dbcffb93c6`, built 2026-06-16T06:32:52Z) - restic `0.18.1`, protocol_version 1 - Reproduced on host `host-A` (Ubuntu 24.04)

steve referenced a pull request that will close this issue

2026-08-22 09:53:37 +01:00

Fix manual forget payload and dry-run execution #39

bobby referenced this issue

2026-08-22 09:54:47 +01:00

Snapshot projection never refreshes after forget — counts are stale until the next backup #40

steve closed this issue

2026-08-22 09:56:12 +01:00

steve referenced this issue

2026-08-22 10:10:20 +01:00

Release v1.1.1 — forget reliability fixes #42

bobby referenced this issue