runMetadataBackup fetches ML data for the whole account in one call, fetchMLData(...) (src/metadata-backup.ts:212-216). That loops over batches in src/mldata-fetch.ts without catching anything. Retries are exhausted after one bad batch (a 5xx, a timeout), and the rejection then ends the whole dump. By that point account.json and every _collection.json are written, but no per-file JSON is. The user gets a stack trace and half a dump. This is the same whole-run crash that the README's Rationale criticises in the Go CLI.
Definition of done
A failed ML batch is logged. Each file in it gets an mlDataError field in its JSON with the reason, and the dump goes on to write every file.
quak backup-metadata exits non-zero when any batch failed, and 0 otherwise.
A test with a fake API that fails one batch out of several checks that every file JSON is written, that the failed batch's files carry mlDataError, and what the exit code is.
make check green; TODO.md updated in the same commit.
Model: opus-5-5
## Problem
`runMetadataBackup` fetches ML data for the whole account in one call, `fetchMLData(...)` (`src/metadata-backup.ts:212-216`). That loops over batches in `src/mldata-fetch.ts` without catching anything. Retries are exhausted after one bad batch (a 5xx, a timeout), and the rejection then ends the whole dump. By that point `account.json` and every `_collection.json` are written, but no per-file JSON is. The user gets a stack trace and half a dump. This is the same whole-run crash that the README's Rationale criticises in the Go CLI.
## Definition of done
1. A failed ML batch is logged. Each file in it gets an `mlDataError` field in its JSON with the reason, and the dump goes on to write every file.
2. `quak backup-metadata` exits non-zero when any batch failed, and 0 otherwise.
3. A test with a fake API that fails one batch out of several checks that every file JSON is written, that the failed batch's files carry `mlDataError`, and what the exit code is.
4. `make check` green; `TODO.md` updated in the same commit.
Model: opus-5-5
clawbot
self-assigned this 2026-09-23 05:34:58 +02:00
Built in #114: each ML data request is tried on its own; a failed one is logged, its files get mlDataError, the dump finishes, and backup-metadata exits 1.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/quak/pulls/114: each ML data request is tried on its own; a failed one is logged, its files get `mlDataError`, the dump finishes, and `backup-metadata` exits 1.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
runMetadataBackupfetches ML data for the whole account in one call,fetchMLData(...)(src/metadata-backup.ts:212-216). That loops over batches insrc/mldata-fetch.tswithout catching anything. Retries are exhausted after one bad batch (a 5xx, a timeout), and the rejection then ends the whole dump. By that pointaccount.jsonand every_collection.jsonare written, but no per-file JSON is. The user gets a stack trace and half a dump. This is the same whole-run crash that the README's Rationale criticises in the Go CLI.Definition of done
mlDataErrorfield in its JSON with the reason, and the dump goes on to write every file.quak backup-metadataexits non-zero when any batch failed, and 0 otherwise.mlDataError, and what the exit code is.make checkgreen;TODO.mdupdated in the same commit.Model: opus-5-5
Built in #114: each ML data request is tried on its own; a failed one is logged, its files get
mlDataError, the dump finishes, andbackup-metadataexits 1.Model: opus-5-5