4 Commits

Author	SHA1	Message	Date
cproudlock	a46058a4dd	Close the last three restore-gate gaps, and make the gate test the real gate ... Three defects that all shared a shape: the restore path looked checked and was not. An unreadable data revision was treated as a legacy set. backup.sh discards the mysql error when reading alembic_version, so a set could be written with an empty datarev; the compatibility check then fell through to the code-to-code head comparison - the very check datarev was introduced to replace - and badged the set restorable on no evidence at all. A manifest that CARRIES the key and left it empty is now refused, while one with no key at all is still the genuine legacy case and keeps the fallback. backup.sh records the failure in run history rather than passing it over in a log line, since the set it just wrote cannot be restored. Dumps were bound to the schema they came from. mysqldump --databases bakes CREATE DATABASE and USE <name> into the file, so restoring onto a site whose MYSQL_DATABASE differs loaded every row into the dump's schema, left the live database untouched, and reported success. New sets are dumped without it and load into the schema named at restore time. Existing sets are still bound, so the gate reads which schema they name and refuses a mismatch instead of restoring beside the live data. Also dropped --no-tablespaces into the main dump: it needs the PROCESS privilege the app user does not have on MySQL 8. The gate's own test carried a copy of the gate. test-restore-datarev.sh re-implemented the predicate in its own shell functions, so it would have stayed green through any drift in restore.sh - including the plugin-chain hole fixed in the previous commit, which it could never have caught. restore.sh now takes RESTORE_CHECK_ONLY, which stops it immediately after the gates having touched nothing, plus overridable paths for the migration and plugin trees. The test drives the shipped script and asserts on its exit code, so the verdict under test IS the verdict that ships. Confirmed non-vacuous by planting a violation: disabling the plugin revision check turns the suite red. Nine cases now, up from five, covering both plugin-chain directions, a plugin the build does not have, and the schema binding. Moving the schema check earlier was prompted by that test: it had been placed after the safety copy, so it needed a live database to reach a verdict it can reach for free. It sits with the other gates now and stops before anything is written. Round-tripped against a real stack after the dump format change: backup, mutate, restore, data back to backup-time state, and the new dumps confirmed to carry no schema name. Suite 2607 passed / 9 skipped. Scope: product	2026-09-06 18:31:37 -04:00
cproudlock	e2705d732a	Gate a restore on every schema chain, not just the core one ... The compatibility gate read alembic_version and nothing else, but plugin schemas move independently of core. Roll the code back to an older plugin revision and the core head can be identical, so a dump carrying plugin tables the code has never heard of passed the gate, loaded - destroying what was there - and only then failed in 'flask plugin upgrade-all' with "Can't locate revision". A failed restore that has already replaced what it was restoring over is the worst outcome this feature can produce, and it was reachable from an ordinary rollback. Backups now stamp the applied revision of every alembic_version_<plugin> table alongside the core one, read from the dumped database the same way. restore.sh checks each against that plugin's own versions directory and refuses before touching anything, naming the plugin and the revision to deploy past. A plugin in the dump that this build does not have at all is refused for the same reason. The list endpoint's compatibility badge asks the same question, so the UI cannot offer a set the restore will reject. Sets taken before the stamp existed carry no dataplugins and keep their old core-only verdict. Their plugin revisions are unknowable, and making every existing set unrestorable to close this would be a worse trade than the gap. Proven against a real stack, reproducing the exact case: core head identical, endpoints data stamped at a revision the build does not have. The restore refused, the live row was still there afterwards, and it stopped early enough that the pre-restore safety copy was never needed. The same set with its true revision restored normally. Suite 2605 passed / 9 skipped, with the gate covered both ways plus the legacy fallback. Scope: product	2026-09-06 18:02:39 -04:00
cproudlock	fa6b99bf91	Finish a restore without a browser, from the set that was asked for ... Closes the three defects in the imported restore path, at Ben's request. Each was proven against a real stack before and after: two backup sets with different data and different instance files, then a restore of the OLDER one, which is the case that was broken. A restore no longer depends on a tab staying open. The backup sidecar has no Flask, so it loads the dump and leaves a sentinel for the api container to run the migrations. The only thing that ever acted on that sentinel was the poll loop of the modal that queued the restore, so closing the tab - or letting a token expire - during the minutes a load takes left the data at the old revision under new code, every query on a newer column failing, and nothing retrying. A watcher in the api container now claims and runs it. The endpoint no longer runs the upgrade at all; it only makes sure something is pending, which is also how a failed upgrade is retried. That takes Alembic out of the request path, where it could outrun the gunicorn worker timeout and be killed mid-chain, leaving a half-applied revision the next attempt trips over. The claim is a rename, because rename(2) is atomic: several workers and a browser poll can race the same sentinel and exactly one wins. A failed upgrade parks itself as .upgrade-failed rather than re-arming, since putting it back would rerun the same broken chain on every poll forever. Instance files come from the set being restored. The restic call asked for 'latest' regardless of which set was named, so restoring anything but the newest paired that set's DATABASE with the NEWEST snapshot's uploads and plugins.json - a mismatch nothing downstream could detect. Now scoped by the set's own tag, which backup.sh has always written. The tree is replaced rather than restored over, so files created after the snapshot are gone afterwards: a restore has to put the site back to the snapshot, not merge into it. Done as a staged swap rather than 'restic restore --delete --target /', because that aims a delete pass at the container root and the cost of getting its filter wrong is the whole filesystem. Nothing destructive happens before a copy is taken. The dump carries DROP TABLE per table with no transaction around it, and the instance tree is replaced wholesale, so a wrong set or a failure part-way through left nothing to go back to. restore.sh now writes a pre-restore-<stamp>/ set - dump, instance tarball and a README saying what it is and how to load it - and refuses to touch anything if that copy cannot be written. Two more found while proving the above, both of which stopped the overlay working at all: * Every script under scripts/backup/ was committed non-executable, while every other .sh in the repo is 755. The compose entrypoints are /opt/backup/watch.sh and backup.sh from a read-only bind mount, so the backup and watcher containers could not start from a clean checkout on any machine, and nothing could fix it at runtime. * Dockerfile.backup could not build without the corporate CA staged. A plain COPY of the gitignored cert fails outright; the trailing-glob form does too, because BuildKit fails a COPY whose pattern matches nothing - which is exactly the case being handled. Copying the directory and testing for the file inside it is the form that works both ways. Verified by building the image with no cert present. Suite 2600 passed / 9 skipped. The finalizer has unit tests covering the atomic claim, the parked failure and the endpoint no longer running the upgrade. Scope: product	2026-09-06 17:38:10 -04:00
cproudlock	6e36df841e	Import the wilm endpoint telemetry, PC Detail rework and backup overlay ... Ports 37 of Benjamin Baker's commits from the wilm branch, mirrored from the corporate GitHub at 7905917c. wilm rides the publication lineage and shares no ancestor with wj, so this is a filtered tree patch rather than a merge: 94 files, and every path the publication export strips (docs/, tools/, mcp/, CLAUDE.md, start-*.sh, .gitea/, the three excluded tests) is held back, because a raw diff would delete each of them from this tree. What comes across: * Endpoint telemetry, phase 2. Physical disk health from two sources, NIC link state, boot type, Defender health, processor/memory/chassis inventory, the listening TCP set, mapped network drives and Windows Update history. Five additive migrations, 0012 through 0016, off the 0011 head. * Mapped drives are collected by a probe running in the interactive user's session, because they do not exist in the agent's session 0. Two Windows sources can disagree about one drive and the worse status wins, so a half-broken share is never rendered as healthy. * Windows events are reported once each, keyed on the channel's own record id, instead of being re-sent whenever a report overlapped the last one. * PC Detail rework: Details cards flow, the hand-written Network card gives way to a full address history, Storage and disk health merge into one card with two sections, Operator Reports and Corporate Tools get their own tabs. * An opt-in restic backup overlay with a third container, restore gated on the dump's own data revision rather than the code head, and backup/restore history. * The agent's version is read from the binary's PE version rather than trusted from the csproj, and the Fleet view gains an Agent Version column. * The enqueue route now asks caller_holds instead of the owner's permissions, which closes the scoped-token elevation on run_script, update_app and system_restart. Held back deliberately: * agent/installer/install-shopdbagent.ps1 stays deleted, as upstream deleted it. The installer that reaches a bay is generated by _install_script() in plugins/endpoints/api/siteagent.py; the standalone script had stopped being shipped and was collecting fixes no endpoint ever ran. * The .gitignore hunk adding docs/*.md. Correct on the publication lineage, where docs/ becomes the wiki and its absence is how the gates detect a published checkout. Here it would silently ignore every new doc. * Their deletions of docs/DEV-BUILD-TEST.md and docs/PLUGIN-HOOKS.md. Upstream those were stubs; here PLUGIN-HOOKS.md is the 31KB document CLAUDE.md points readers at. * Five zero-byte files committed by an accidental `git add -A`, a run log from the author's own machine, and docs/notes/, which is working scratch that says so in its own header and belongs in devnotes/ on this side. Carried with the import so it lands green: the 17 new routes are described in docs/api-inventory.json with the spec and project map regenerated, and two new frontend specs read fixtures through fileURLToPath(URL) which node rejects under jsdom's own URL global. Suite 2591 passed / 9 skipped; frontend 391 passed; naming, style and doc gates clean. Scope: product	2026-09-06 16:47:24 -04:00