Files
picpeak/backend/__tests__/services/localStorageUsage.test.js
T
Paul Nothaft 849a5807b7 fix(admin): make "Storage used" report storage used (#1164) (#1170)
* fix(admin): make "Storage used" report storage used (#1164)

The tile summed photos.size_bytes — the catalogued size of the ORIGINALS,
which has no relationship to the disk PicPeak runs on. In reference mode those
files are never copied and sit on the NAS; duplicate rows counted the same
file twice (#1162); and it ignored everything PicPeak genuinely does write
locally: thumbnails, previews, hero renditions, watermarks and the per-event
download cache. The reporter's tile read ~80 GB against 21 GB of real usage.

Worse than the label: the same number drove the storage soft-limit warning bar
and, via /storage/info, the recommended soft limit — so a reference-mode
install got a disk-capacity recommendation computed from bytes that are not on
the disk.

- new localStorageUsage service walks the storage root and reports the total
  plus a breakdown. Walking rather than summing DB columns is the point:
  thumbnail/preview/hero rows record a key and never a byte count, and orphans
  from a deleted event or an interrupted import are real bytes. Symlinks are
  not followed, so a link into the media mount cannot put the NAS back in the
  total. Cached for 5 minutes, since the dashboard polls.
- the dashboard tile and /storage/info now report that, with the catalogued
  figure kept and labelled as such next to it. A failed measurement reads as
  "unavailable" rather than substituting a number that means something else.

On the local rig: 64.37 MB used against 15.75 MB catalogued, of which 27.9 MB
is watermarks and 6.8 MB is download cache — none of which the old figure
could see.

Not addressed here: `.download-cache/all.zip` still has no TTL or size cap. It
is now at least visible in the breakdown, which is what makes the case for
capping it.

* fix(admin): exclude the media share from local storage usage (#1164)

External review found the walk could reintroduce the exact over-count it
replaces.

EXTERNAL_MEDIA_ROOT's compose default is `<storage>/external-media`, where the
NAS is bind-mounted. That is a plain directory, not a symlink, so the symlink
guard did not cover it and the walk descended into the share — putting every
referenced original back into a figure whose whole purpose is to leave them
out, and comparing NAS bytes against statfs() of the local disk. On the
reference-mode installs this issue is about, that is the failure mode
reappearing inside its own fix.

The configured root is now skipped when it lies inside the storage root, and
the result reports which path was excluded. A directory that merely shares the
name is still counted, because those really are local bytes.

Also from the review:

- concurrent cold-cache callers now share one walk. /dashboard/stats,
  /storage/info and the sidebar are routinely requested together, and each was
  starting its own stat-per-file traversal of the whole library.
- storage_partial is surfaced in the StorageInfo type and the sidebar tile, not
  just the dashboard and analytics cards. An unreadable subtree makes the total
  a floor, and a floor silently compared against a soft limit reads as "safely
  under".

* fix(admin): do not report a disk walk on an S3 backend (#1164)

Second review round.

S3 installs were regressed. With STORAGE_BACKEND=s3 the originals, renditions,
archives and download caches are objects in the bucket and STORAGE_PATH holds
only incidental local files — so the walk reported near-zero and the soft-limit
recommendation was derived from it. Those installs now keep the catalogued
figure, which is the approximation they had before this PR, and the response
says which measurement it is (`storage_measurement: 'disk' | 'catalog'`) so the
UI labels it instead of implying a disk measurement that never happened.

The Settings → Status storage card ignored storage_partial, formatting a lower
bound as exact and deriving the limit percentage from it — so an unreadable
subtree could read as safely under the limit. It now carries the same `+`
marker as the sidebar and dashboard.

* fix(admin): stop rendering an absent measurement as zero usage (#1164)

Third review round, two findings.

The analytics storage bar coerced a null measurement to 0, drawing an empty
bar labelled "0% of limit" and suppressing the over-limit state — reading as
plenty of room at exactly the moment nothing is known. It now shows the
catalogued figure on S3, where that IS the available answer, and says "no
measurement available" rather than inventing a percentage when there is none.

/storage/info walked the filesystem before checking the backend and then threw
the result away on S3. The sidebar polls that endpoint, so a migrated install
still holding a large local tree paid a full stat-per-file traversal on every
cold cache for nothing. Gated before the walk, as the dashboard route already
was.

* fix(admin): tell "no disk to measure" apart from "the measurement failed" (#1164)

External review of the stable twin.

Both were reported as `storage_measurement: 'catalog'`, so a failed local walk
made the dashboard claim the objects live in S3. They are different things —
one is a fact about the install, the other is a fault — and there is now an
`unavailable` state for the second.

The analytics percentage could reach the billions. `safeSoftLimit` fell back to
`storageUsed || 1`, and on S3 that is null → 1, while the figure beside it came
from `catalogedBytes`. An editor or viewer holds `analytics.view` but not
`settings.view`, so `/storage/info` 403s for them and `storageInfo` is
undefined — which is exactly when that fallback fires. It now falls back to the
measured figure, and suppresses the percentage entirely when there is no real
limit rather than dividing usage by itself and always reading 100%.

Also lands the AnalyticsPage half of the previous round, which the commit
message claimed but the commit did not contain — only its backend counterpart
was staged. The stable twin has carried it since it was written, so this is the
parity gap in the unusual direction.

---------

Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>
2026-08-26 08:53:39 +02:00

202 lines
8.0 KiB
JavaScript

/**
* "Storage used" has to mean storage used (#1164).
*
* The tile summed photos.size_bytes, so on a reference-mode install it
* reported the size of files sitting on a NAS — the reporter's read ~80 GB
* against 21 GB of real local usage — while omitting everything PicPeak does
* write locally, including an 11.8 GB download-cache zip.
*
* These pin the measurement against a real directory tree, since the whole
* point is counting bytes that are actually there.
*/
const path = require('path');
const fs = require('fs');
const os = require('os');
const {
measureLocalStorageUsage,
resetLocalStorageUsageCache,
} = require('../../src/services/localStorageUsage');
describe('localStorageUsage (#1164)', () => {
let root;
const write = async (rel, bytes) => {
const full = path.join(root, rel);
await fs.promises.mkdir(path.dirname(full), { recursive: true });
await fs.promises.writeFile(full, Buffer.alloc(bytes));
};
beforeEach(async () => {
root = await fs.promises.mkdtemp(path.join(os.tmpdir(), 'picpeak-usage-'));
process.env.STORAGE_PATH = root;
delete process.env.EXTERNAL_MEDIA_ROOT;
jest.resetModules();
resetLocalStorageUsageCache();
});
afterEach(async () => {
await fs.promises.rm(root, { recursive: true, force: true }).catch(() => {});
delete process.env.STORAGE_PATH;
delete process.env.EXTERNAL_MEDIA_ROOT;
resetLocalStorageUsageCache();
});
it('counts every byte under the storage root', async () => {
await write(path.join('events', 'active', 'wed', 'individual', 'a.jpg'), 1000);
await write(path.join('thumbnails', 'a.jpg'), 100);
await write(path.join('previews', 'a.jpg'), 300);
const usage = await measureLocalStorageUsage();
expect(usage.total).toBe(1400);
expect(usage.files).toBe(3);
});
it('breaks the total down by what the bytes are', async () => {
// The specific complaint: the derived artefacts PicPeak writes were
// invisible, so "what is filling my disk" had no answer in the UI.
await write(path.join('events', 'active', 'wed', 'individual', 'a.jpg'), 1000);
await write(path.join('events', 'archived', 'old.zip'), 5000);
await write(path.join('thumbnails', 'a.jpg'), 100);
await write(path.join('previews', 'a.jpg'), 300);
await write(path.join('heroes', 'a.jpg'), 200);
await write(path.join('watermarks', 'a.jpg'), 700);
await write(path.join('uploads', 'logo.png'), 50);
const { breakdown } = await measureLocalStorageUsage();
expect(breakdown).toMatchObject({
originals: 1000,
archives: 5000,
thumbnails: 100,
previews: 300,
heroes: 200,
watermarks: 700,
uploads: 50,
});
});
it('files the download cache separately from the originals it sits among', async () => {
// `.download-cache` lives INSIDE the event directory, so the naive rule
// files an 11.8 GB zip as photography. It is the one bucket that is pure
// disposable cache and the one an admin most needs to see.
await write(path.join('events', 'active', 'wed', 'individual', 'a.jpg'), 1000);
await write(path.join('events', 'active', 'wed', '.download-cache', 'all.zip'), 9000);
const { breakdown, total } = await measureLocalStorageUsage();
expect(breakdown.downloadCache).toBe(9000);
expect(breakdown.originals).toBe(1000);
expect(total).toBe(10000);
});
it('counts orphans no database row knows about', async () => {
// A deleted event's leftovers and an interrupted import's thumbnails are
// real bytes on a real disk. Summing DB columns would miss them, which is
// half of why this walks instead.
await write(path.join('thumbnails', 'ext999_gone.jpg'), 777);
expect((await measureLocalStorageUsage()).total).toBe(777);
});
it('reports zero on a fresh install rather than failing', async () => {
const usage = await measureLocalStorageUsage();
expect(usage.total).toBe(0);
expect(usage.partial).toBe(false);
});
it('survives a storage root that does not exist', async () => {
process.env.STORAGE_PATH = path.join(root, 'nope');
resetLocalStorageUsageCache();
const usage = await measureLocalStorageUsage();
// ENOENT on the root is a fresh/misconfigured install, not a partial read.
expect(usage.total).toBe(0);
expect(usage.partial).toBe(false);
});
it('does not walk the media share bind-mounted under the storage root', async () => {
// The compose default puts EXTERNAL_MEDIA_ROOT at <storage>/external-media,
// where the NAS is bind-mounted — a plain directory, not a symlink. Walking
// it would put every referenced original back into a figure that exists to
// leave them out, which is the over-count this measurement replaces.
await write(path.join('thumbnails', 'a.jpg'), 100);
await write(path.join('external-media', 'nas', 'huge.jpg'), 50000);
process.env.EXTERNAL_MEDIA_ROOT = path.join(root, 'external-media');
jest.resetModules();
const svc = require('../../src/services/localStorageUsage');
svc.resetLocalStorageUsageCache();
const usage = await svc.measureLocalStorageUsage();
expect(usage.total).toBe(100);
expect(usage.excludedExternalRoot).toBe(path.join(root, 'external-media'));
});
it('still counts a directory that merely looks like the media share', async () => {
// Only the CONFIGURED root is skipped. An install whose media lives
// elsewhere keeps whatever is in this directory in the total, because
// those really are local bytes.
await write(path.join('external-media', 'leftover.jpg'), 700);
// The production shape: the share is mounted well outside the storage root.
const elsewhere = await fs.promises.mkdtemp(path.join(os.tmpdir(), 'picpeak-nas-elsewhere-'));
process.env.EXTERNAL_MEDIA_ROOT = elsewhere;
jest.resetModules();
const svc = require('../../src/services/localStorageUsage');
svc.resetLocalStorageUsageCache();
const usage = await svc.measureLocalStorageUsage();
expect(usage.total).toBe(700);
expect(usage.excludedExternalRoot).toBeNull();
await fs.promises.rm(elsewhere, { recursive: true, force: true });
});
it('shares one walk between concurrent cold-cache callers', async () => {
// /dashboard/stats and /storage/info are routinely requested together, and
// the sidebar adds a third. Each starting its own full stat-per-file walk
// multiplies the cost on exactly the large libraries where it hurts.
await write(path.join('thumbnails', 'a.jpg'), 100);
const readdir = jest.spyOn(fs.promises, 'readdir');
const [a, b, c] = await Promise.all([
measureLocalStorageUsage(),
measureLocalStorageUsage(),
measureLocalStorageUsage(),
]);
expect([a.total, b.total, c.total]).toEqual([100, 100, 100]);
// One walk: the storage root plus its one subdirectory.
expect(readdir).toHaveBeenCalledTimes(2);
readdir.mockRestore();
});
it('caches, and honours force', async () => {
await write(path.join('thumbnails', 'a.jpg'), 100);
expect((await measureLocalStorageUsage()).total).toBe(100);
await write(path.join('thumbnails', 'b.jpg'), 400);
// One stat per file is not free; the dashboard polls.
expect((await measureLocalStorageUsage()).total).toBe(100);
expect((await measureLocalStorageUsage({ force: true })).total).toBe(500);
});
it('does not follow a symlink out of the storage root', async () => {
// A link into EXTERNAL_MEDIA_ROOT would add the NAS back into the local
// total — reinstating the exact confusion this replaces.
const outside = await fs.promises.mkdtemp(path.join(os.tmpdir(), 'picpeak-nas-'));
await fs.promises.writeFile(path.join(outside, 'huge.jpg'), Buffer.alloc(50000));
await fs.promises.mkdir(path.join(root, 'events'), { recursive: true });
await fs.promises.symlink(outside, path.join(root, 'events', 'nas'), 'dir');
const usage = await measureLocalStorageUsage();
expect(usage.total).toBe(0);
await fs.promises.rm(outside, { recursive: true, force: true });
});
});