quak backup asks the server for changes every 3 seconds for its whole run #183

New Issue

2026-10-14T01:31:47+02:00

clawbot commented

2026-10-14 01:31:47 +02:00

Problem

backupCommand in src/cli-commands.ts opens its library with the default refresh interval of 3 seconds. The library then asks the server for changes 3 seconds after each refresh ends, for the whole run, which can last hours. Each of those refreshes also starts an ML data pass (fetchMLDataNow in refreshCycle, src/library/index.ts) that asks again for every file Ente holds no ML data for, in requests of 200, so on an account with many such files the backup sends ML data requests without a break. That is at least 1,200 requests an hour that the backup never uses: it lists its files once, from the refresh it waits for at the start. The read commands open their library with an interval of 3600 seconds for this reason (openReadLibrary), so that no second refresh fires during the command.

Definition of done

quak backup opens its library so that no refresh starts on a timer while it runs, as the read commands do. The one refresh the backup waits for at the start stays.
A test: a backup that runs longer than 3 seconds (held open by a slow content source, or with fake timers) makes exactly the refreshes it waits for, counted at the client's collectionsSince.
README: nothing to change unless it says otherwise; check "Running the backup from cron" and "Backup layout".

Model: opus-5-5

## Problem `backupCommand` in `src/cli-commands.ts` opens its library with the default refresh interval of 3 seconds. The library then asks the server for changes 3 seconds after each refresh ends, for the whole run, which can last hours. Each of those refreshes also starts an ML data pass (`fetchMLDataNow` in `refreshCycle`, `src/library/index.ts`) that asks again for every file Ente holds no ML data for, in requests of 200, so on an account with many such files the backup sends ML data requests without a break. That is at least 1,200 requests an hour that the backup never uses: it lists its files once, from the refresh it waits for at the start. The read commands open their library with an interval of 3600 seconds for this reason (`openReadLibrary`), so that no second refresh fires during the command. ## Definition of done - `quak backup` opens its library so that no refresh starts on a timer while it runs, as the read commands do. The one refresh the backup waits for at the start stays. - A test: a backup that runs longer than 3 seconds (held open by a slow content source, or with fake timers) makes exactly the refreshes it waits for, counted at the client's `collectionsSince`. - README: nothing to change unless it says otherwise; check "Running the backup from cron" and "Backup layout". Model: opus-5-5

clawbot added this to the 1.0.0 milestone 2026-10-14 01:33:13 +02:00

clawbot referenced this issue from a commit

2026-10-14 02:29:07 +02:00

quak backup no longer refreshes its library on a timer (closes #183)

clawbot referenced a pull request that will close this issue

2026-10-14 02:29:22 +02:00

quak backup no longer refreshes its library on a timer (closes #183) #190

clawbot commented

2026-10-14 02:29:27 +02:00

Built in #190: quak backup opens its library with refreshIntervalSeconds: Infinity, which the library now takes as no background timer, so the backup refreshes only as it starts.

Model: opus-5-5

Built in https://git.eeqj.de/sneak/quak/pulls/190: `quak backup` opens its library with `refreshIntervalSeconds: Infinity`, which the library now takes as no background timer, so the backup refreshes only as it starts. Model: opus-5-5

clawbot referenced this issue from a commit

2026-10-14 03:50:50 +02:00

quak backup no longer refreshes its library on a timer (closes #183)

clawbot referenced this issue from a commit

2026-10-14 04:10:16 +02:00

quak backup no longer refreshes its library on a timer (closes #183)

clawbot closed this issue

2026-10-14 04:10:16 +02:00

Sign in to join this conversation.