Files
shopdb-flask/docs/PROJECT-MAP.md
cproudlock fa6b99bf91
Some checks failed
CI / naming (push) Successful in 4s
CI / frontend (push) Successful in 14s
CI / migrations-mysql (push) Failing after 14s
CI / backend (push) Failing after 4m57s
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

4.5 KiB

Project map

Derived from the code on every regeneration. If something here is wrong, the code changed and the map was not regenerated - fix it by running the generator, never by editing this file.

Versions

series value governed by
product __version__ 0.12.0 ADR-007
plugin contract __contract_version__ 0.31.0 ADR-002

They move independently. A contract bump is not a release.

Alembic chains (ADR-008)

Core runs with flask db upgrade; every plugin chain runs with flask plugin upgrade-all. Both are needed on a deploy.

chain head
core 7d41_drop_guest_tools_secrets
backups backups0003clearlastseen
computers computers0004policies
employees employees0002photo
endpoints endpoints0016dellupdates
geenforce geenforce0004minlib
guides guides0001baseline
knowledgebase knowledgebase0001anchor
machines machines0002rename
measuringtools measuringtools0001baseline
network network0003prefix
notifications notifications0005boardorder
printedparts printedparts0004txnrev
printers printers0005observedqueues
slides slides0001anchor
tools tools0001securesend
usb usb0004checkinidentity
warranty warranty0002proof

Bundled plugins (17)

plugin version core_version owns migrations
backups 1.0.0 >=0.16.0,<1.0.0 yes
computers 1.0.0 >=0.20.0,<1.0.0 yes
employees 1.0.0 >=0.1.0,<1.0.0 yes
endpoints 0.1.0 >=0.20.0,<1.0.0 yes
geenforce 0.1.0 >=0.18.0,<1.0.0 yes
guides 1.0.0 >=0.1.0,<1.0.0 yes
knowledgebase 1.0.0 >=0.1.0,<1.0.0 yes
machines 1.0.0 >=0.20.0,<1.0.0 yes
measuringtools 1.0.0 >=0.20.0,<1.0.0 yes
network 1.0.0 >=0.20.0,<1.0.0 yes
notifications 1.0.0 >=0.1.0,<1.0.0 yes
printedparts 0.1.0 >=0.16.0,<1.0.0 yes
printers 1.0.0 >=0.20.0,<1.0.0 yes
slides 2.0.0 >=0.2.0,<1.0.0 yes
tools 1.0.0 >=0.16.0,<1.0.0 yes
usb 1.0.0 >=0.1.0,<1.0.0 yes
warranty 1.0.0 >=0.2.0,<1.0.0 yes

Manifest-less directories under plugins/ are core frontend surface and always ship: applications.

Architecture decisions

ADR title status
ADR-001-asset-as-platform-contract.md ADR-001: Asset model is the platform contract ACCEPTED
ADR-002-plugin-versioning.md ADR-002: Plugin contract versioning ACCEPTED
ADR-003-plugin-distribution.md ADR-003: Plugin distribution model ACCEPTED
ADR-004-deployment-topology.md ADR-004: Deployment topology (per-site instances) ACCEPTED
ADR-005-equipment-vs-measuringtools.md ADR-005: Equipment plugin scope vs measuringtools plugin ACCEPTED
ADR-006-collector-contract.md ADR-006: Plugin collector contract pattern ACCEPTED
ADR-007-product-versioning-and-releases.md ADR-007: Product versioning and releases ACCEPTED
ADR-008-plugin-migration-ownership.md ADR-008: Plugin migration ownership (per-plugin chains from the cutover) ACCEPTED
ADR-009-frontend-plugin-gating.md ADR-009: Frontend plugin gating ACCEPTED
ADR-010-frontend-plugin-hooks.md ADR-010: Frontend plugin hook contract ACCEPTED
ADR-011-machines-rename.md ADR-011: Rename the equipment domain to machines; retype the models catalog with modeltypes ACCEPTED
ADR-012-geenforce-manifest-ownership.md ADR-012: GE-Enforce manifest ownership in shopdb ACCEPTED
ADR-013-plugin-catalog-and-lean-builds.md ADR-013: Plugin Catalog, Curated Shelf, and Lean Per-Site Builds ACCEPTED
ADR-014-schema-lean-per-site.md ADR-014: Schema-lean per-site builds (retire cross-plugin FKs, lift plugin tables) ACCEPTED
ADR-015-site-specific-configuration.md ADR-015: Where a site's own data is allowed to live ACCEPTED
ADR-016-credential-delivery.md ADR-016: Credential delivery to the fleet ACCEPTED (decided; NOT yet implemented -
ADR-017-buildings-and-levels.md ADR-017: Buildings and levels as the map model ACCEPTED
ADR-018-metrology-instruments-are-machines.md ADR-018: Metrology instruments are machines ACCEPTED

Size

  • test functions defined: 1847 (parametrised cases collect higher)
  • documented API paths: 376 (docs/openapi.json, regenerate with scripts/gen_openapi.py)