No backup, restore or upgrade guidance anywhere in the README #210

New Issue

clawbot · 2026-08-20T05:48:41+02:00

clawbot commented

2026-08-20 05:48:41 +02:00

Grepping the 1990-line README for backup|restore|upgrade|migration finds nothing on any of them.

An operator deploying this has no answer to: which files must I back up, can I copy them while the service is running, how do I restore, and what happens to my data when I pull a newer image. Schema changes ride on GORM AutoMigrate (internal/database/database.go:179-191) with no schema versioning and no rollback path, so a downgrade after an upgrade has undefined behaviour and nothing says so.

The state is not in one file, which is the part that most needs writing down: webhooker.db plus one events-{id}.db per webhook plus archive-{id}.db for database targets, all under DATA_DIR.

Definition of done — a README section covering:

exactly which files constitute the backup set, with the per-webhook and archive naming spelled out
whether a hot copy is safe, and the safe procedure if it is not (SQLite .backup, or stop-copy-start)
restore: what to put back and any ownership or permission requirement, given the container runs as UID 1000
upgrade: AutoMigrate runs on start, back up first, downgrade is unsupported — stated plainly rather than implied
a note that event databases contain the payload bodies, and, until the credential-leak issue filed alongside this is fixed, target credentials too

Docs-only, so it skips the adversarial review gate, but it does not skip make fmt.

Grepping the 1990-line README for `backup|restore|upgrade|migration` finds nothing on any of them. An operator deploying this has no answer to: which files must I back up, can I copy them while the service is running, how do I restore, and what happens to my data when I pull a newer image. Schema changes ride on GORM `AutoMigrate` (`internal/database/database.go:179-191`) with no schema versioning and no rollback path, so a downgrade after an upgrade has undefined behaviour and nothing says so. The state is not in one file, which is the part that most needs writing down: `webhooker.db` plus one `events-{id}.db` per webhook plus `archive-{id}.db` for database targets, all under `DATA_DIR`. Definition of done — a README section covering: - exactly which files constitute the backup set, with the per-webhook and archive naming spelled out - whether a hot copy is safe, and the safe procedure if it is not (SQLite `.backup`, or stop-copy-start) - restore: what to put back and any ownership or permission requirement, given the container runs as UID 1000 - upgrade: `AutoMigrate` runs on start, back up first, downgrade is unsupported — stated plainly rather than implied - a note that event databases contain the payload bodies, and, until the credential-leak issue filed alongside this is fixed, target credentials too Docs-only, so it skips the adversarial review gate, but it does not skip `make fmt`.

clawbot added this to the 1.0.0 milestone 2026-08-20 05:48:41 +02:00

clawbot referenced this issue

2026-08-20 05:49:42 +02:00

1.0/mvp #33

clawbot referenced this issue

2026-08-20 05:52:42 +02:00

Encrypt credential-bearing target config at rest in webhooker.db #212

clawbot referenced this issue

2026-08-20 05:52:47 +02:00

Target credentials leak into the per-webhook event databases via GORM association upsert #206

clawbot referenced this issue from a commit

2026-08-20 06:04:03 +02:00