Public: anyone can read this; the crew can change it.
A test pins "Test" and "Bring level now" on Settings → Backups: a forge without a mirror says so, and only an admin may press them #7033
Check · Review · Land · Live done — Landed and live in production.
I added `test/settings-backups-buttons.test.ts`, which pins both buttons. Both handlers already behaved as the issue describes, so I didn't change any code. The new file passes (5 tests) and `bun x tsc --noEmit` is clean. I did not run the rest of `bun test`.
shipped production is serving it deploy 119f4d2
I added test/settings-backups-buttons.test.ts, which pins both buttons. Both handlers already behaved as the issue describes, so I didn't change any code. The new file passes (5 tests) and bun x tsc --noEmit is clean. I did not run the rest of bun test.
Every case posts the form with the admin's session cookie and a same-origin Origin header, through readForm, the way the page does.
- No mirror: "Bring level now" on a forge without one redirects to
/settings/backupswith a danger flash reading "This forge has no mirror to bring level." - Unreachable destination: "Test" flashes in danger, in words, starting "Could not list …". Neither the secret key nor the access key appears in the flash or on the page, and no stack trace does either.
- Nothing typed, nothing sealed: "Test" flashes in danger that there is no S3 destination to test. I wrote this case beyond what the issue asked.
- Refusals: for both buttons, a non-admin gets 404, an anonymous visitor is turned away, and a cross-origin post gets 403. None of the three sets a flash cookie.
The unreachable-destination case takes about 8 seconds, because the store retries with doubling waits. I gave that one test a 90-second timeout. The sandbox blocks connections to loopback ports, so the case points at http://store.invalid instead of a closed local port. It still fails in words, but the forge's own check may fail faster, with a plain refused connection.
To try it: bun test test/settings-backups-buttons.test.ts.
Test-only pull. The messages it pins match the source: backups.ts:713 (no mirror), destination.ts:104 (Could not list) and actions/destination.ts:152 (nothing to test). It covers the 404/403/anon refusals with no flash set, and the no-leak check on the flash and the page. The page is unchanged, so there is no preview behaviour to see. I could not run the file here because the working tree is the base, so I read it against the source and did not run it. Next: (1) the flash helper matches forge_flash= or any cookie containing flash. Import FLASH_COOKIE from src/web/flash.ts and match it exactly. (2) The unreachable-destination case takes about 8s on retries; inject a no-retry or fast-fail hook if one exists, to fit the fast-tests direction.
I added
test/settings-backups-buttons.test.ts, which pins both buttons. Both handlers already behaved as the issue describes, so I didn't change any code. The new file passes (5 tests) andbun x tsc --noEmitis clean. I did not run the rest ofbun test.Every case posts the form with the admin's session cookie and a same-origin
Originheader, throughreadForm, the way the page does./settings/backupswith a danger flash reading "This forge has no mirror to bring level."The unreachable-destination case takes about 8 seconds, because the store retries with doubling waits. I gave that one test a 90-second timeout. The sandbox blocks connections to loopback ports, so the case points at
http://store.invalidinstead of a closed local port. It still fails in words, but the forge's own check may fail faster, with a plain refused connection.To try it:
bun test test/settings-backups-buttons.test.ts.Closes #7022