twooey
1020a496ab
- SupplierOffer::insert(): now checks $wpdb->insert()'s return value and
throws, matching Work/Edition/Isbn (the one Catalog class that hadn't
been hardened this way). Work::set_product_id() gets the same treatment
(was flagged low-severity but same fix, bundled here) — a real update
failure now counts as a per-work sync failure instead of silently
leaving a stale wc_product_id pointer.
- SupplierOffer: fetched_at was written via current_time('mysql') (site-
local) while expires_at (SyntheticOfferGenerator) is written in UTC, and
best_offer_for_isbns() compared against site-local time too — a mismatch
masked today only because dev's gmt_offset is 0. Switched both writer and
reader to current_time('mysql', true) (UTC). Verified the read path
still finds all active offers correctly under a simulated -5 (US
Eastern) offset, not just at offset 0.
- HardcoverAdapter: rate-limit throttling moved from "once per work" (in
Commands.php) to "once per actual HTTP request" (inside query() itself).
find_book()'s ISBN-then-title/author fallback can fire two real requests
per work — under the old scheme both shared one throttle sleep, roughly
doubling the real request rate against a beta API. query() also now
retries network errors/5xx/429 up to 3x (mirroring
OpenLibraryAdapter::get_with_retry()), while a GraphQL-level `errors` field
or other 4xx throws immediately (retrying a rejected query can't fix it).
Commands.php adds a 5-consecutive-failure circuit breaker so a bad token
or a wrong field in the still-unverified schema can't silently burn
through the whole catalog with zero progress. Verified all of this
directly against Hardcover's real API with a deliberately invalid token:
5 fast (non-retried) 401s, correct abort message, and confirmed the
failed works were NOT marked synced (so a real token can retry them).
- restore.sh: now drops and recreates the target database before restoring
the dump, and clears the uploads directory before extracting the
archive — previously both restored on top of existing state, so a stray
table or file NOT in the backup would silently survive a restore drill.
Verified end-to-end against a real local staging stack: planted a stray
table and a stray upload file after taking a backup, ran restore.sh, and
confirmed both were gone afterward while the actual backed-up data (20
works, a known upload file) came back correctly. Also fixed a real
permission gap hit during that same test: a fresh volume's uploads dir
is root-owned until something chowns it, which broke the new www-data
clear step — now clears as root and chowns to www-data afterward, which
also means restore self-heals the exact root-owned-uploads class of bug
fixed earlier this session for the cron sidecar.
- poll-deploy.sh: added a non-blocking flock so a deploy that runs longer
than the cron interval can't have a second poll fire mid-deploy and race
its git checkout/reset against the same live working tree. Verified: a
concurrent run correctly skips instantly while the lock is held, and
proceeds normally once it's released. (Full atomicity of the live PHP
file swap under real traffic is a bigger architectural question —
blue-green or symlinked releases — flagged to the user rather than
attempted here.)
- backup.sh: now also archives .env.<environment> itself (chmod 600) and
includes it in the off-host rclone sync alongside the DB dump and
uploads archive. Every API key and both DB passwords previously lived
only on the host in this one gitignored file — losing the host lost all
of it even with DB/uploads backups intact.
65 lines
3.4 KiB
Bash
Executable File
65 lines
3.4 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Restores a backup INTO STAGING ONLY. Deliberately has no production path —
|
|
# the launch gate is "a full backup has been restored into staging," never
|
|
# production overwritten by a drill.
|
|
set -euo pipefail
|
|
|
|
DB_DUMP="${1:?Usage: restore.sh <db-dump.sql.gz> <uploads.tar.gz>}"
|
|
UPLOADS_ARCHIVE="${2:?Usage: restore.sh <db-dump.sql.gz> <uploads.tar.gz>}"
|
|
REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
|
cd "$REPO_ROOT"
|
|
|
|
ENV_FILE=".env.staging"
|
|
export ENVIRONMENT=staging
|
|
# shellcheck source=lib/env.sh
|
|
source "$REPO_ROOT/deploy/lib/env.sh"
|
|
DB_NAME_VALUE="$(env_get "$ENV_FILE" DB_NAME)"
|
|
: "${DB_NAME_VALUE:?set DB_NAME in ${ENV_FILE}}"
|
|
|
|
# See deploy.sh for why: Compose warns on any $-shaped value in --env-file
|
|
# even when unused, so DB_PASSWORD/DB_ROOT_PASSWORD are filtered out of the
|
|
# copy Compose actually sees.
|
|
COMPOSE_ENV_FILE="$(mktemp)"
|
|
trap 'rm -f "$COMPOSE_ENV_FILE"' EXIT
|
|
grep -Ev '^(DB_PASSWORD|DB_ROOT_PASSWORD)=' "$ENV_FILE" > "$COMPOSE_ENV_FILE"
|
|
|
|
COMPOSE="docker compose -p bookstore-staging -f docker-compose.yml -f docker-compose.staging.yml --env-file ${COMPOSE_ENV_FILE}"
|
|
|
|
echo "!! this OVERWRITES the staging database and uploads !!"
|
|
read -r -p "type 'restore' to continue: " confirm
|
|
[[ "$confirm" == "restore" ]] || { echo "aborted"; exit 1; }
|
|
|
|
echo "==> dropping and recreating the staging database for a clean restore"
|
|
# Without this, a table present in staging but absent from the dump (a stray
|
|
# leftover from before a schema change, a one-off test table) would silently
|
|
# survive "restore" and go undetected — a drill could pass while masking data
|
|
# genuinely missing from the backup. Grants tied to a non-root user are keyed
|
|
# to the database NAME in MariaDB's privilege tables, not the schema object's
|
|
# identity, so MARIADB_USER's access survives a same-name drop+recreate
|
|
# (verified directly against a throwaway database before relying on this).
|
|
$COMPOSE exec -T db sh -c "exec mariadb -u root -p\"\$(cat /run/secrets/db_root_password)\" -e 'DROP DATABASE IF EXISTS \`${DB_NAME_VALUE}\`; CREATE DATABASE \`${DB_NAME_VALUE}\`;'"
|
|
|
|
echo "==> restoring database"
|
|
gunzip -c "$DB_DUMP" | $COMPOSE exec -T db sh -c "exec mariadb -u\"\$MARIADB_USER\" -p\"\$(cat /run/secrets/db_password)\" \"\$MARIADB_DATABASE\""
|
|
|
|
echo "==> clearing existing uploads before restoring"
|
|
# Same reasoning as the database above: extracting on top of whatever's
|
|
# already there would let a file missing from the archive hide behind one
|
|
# that happens to still be present from before the drill. Runs as root
|
|
# (unlike the tar extraction below), not www-data: the uploads directory
|
|
# itself can be root:root on a volume that's never had a www-data-owned
|
|
# write land in it yet (the official image's entrypoint creates it on first
|
|
# boot, before dropping to www-data) — confirmed directly against a fresh
|
|
# staging volume. chown afterward so the subsequent www-data tar extraction
|
|
# below can actually write into it.
|
|
$COMPOSE run --rm -T wordpress sh -c \
|
|
"find /var/www/html/wp-content/uploads -mindepth 1 -delete && chown www-data:www-data /var/www/html/wp-content/uploads"
|
|
|
|
echo "==> restoring uploads"
|
|
ARCHIVE_DIR="$(cd "$(dirname "$UPLOADS_ARCHIVE")" && pwd)"
|
|
ARCHIVE_NAME="$(basename "$UPLOADS_ARCHIVE")"
|
|
$COMPOSE run --rm -T -u www-data -v "${ARCHIVE_DIR}:/restore:ro" wordpress \
|
|
tar -xzf "/restore/${ARCHIVE_NAME}" -C /var/www/html/wp-content
|
|
|
|
echo "==> restore complete — verify the site before treating the drill as passed"
|