Testing Migrations for web scraper

This commit is contained in:
Max committed 2026-11-03 13:03:45 -07:00
1 parent 9804771a5b
commit 1b47cb0d35
2 files changed
+145 -4

No files matched your search

+71 -4
View File
@@ -156,6 +156,35 @@ HAS_EXISTING_SCHEMA=$(sql "SELECT COUNT(*) FROM information_schema.TABLES
if [ "${HAS_MIGRATION_TABLE:-0}" -eq 0 ] && [ "${HAS_EXISTING_SCHEMA:-0}" -gt 0 ]; then
echo "Existing schema found with no migration history -- baselining."
#
# Report drift BEFORE recording the baseline.
#
# `migrate resolve` records a migration without executing it, so baselining
# a database that does not actually match the schema leaves it permanently
# short of those objects while Prisma reports everything as applied. That
# is exactly how production ended up missing scrape_cache: this script
# previously inferred "the attachment table exists" => "the whole schema
# exists", which is not the same claim.
#
# Later migrations are additive and idempotent, so drift is recoverable --
# but the operator should see it rather than discover it from a log line
# days later.
#
if ! prisma migrate diff \
--from-config-datasource \
--to-schema prisma/schema.prisma \
--exit-code >/dev/null 2>&1
then
echo ""
echo "NOTE: this database does not yet match prisma/schema.prisma."
echo " Baselining 0_init anyway, then applying later migrations to"
echo " converge it. Differences:"
prisma migrate diff --from-config-datasource --to-schema prisma/schema.prisma \
| sed 's/^/ /'
echo ""
fi
echo "Marking 0_init as already applied (NOT executing it)."
prisma migrate resolve --applied 0_init
echo ""
@@ -207,14 +236,52 @@ echo ""
AND TABLE_COLLATION <> 'utf8mb4_general_ci';
"
# The FULLTEXT index backs Attachment.textSearch. If a migration ever converts
# it to a BTREE index, attachment search silently returns nothing -- so fail
# loudly here rather than letting that ship.
#
# Assert that everything the application actually needs now exists.
#
# This is the check that was missing. `prisma migrate deploy` reporting success
# only means the recorded migrations ran -- it says nothing about whether the
# database ended up in the intended shape, which is precisely how production
# could pass this script and still log
# "Scraper: DISABLED - missing table scrape_cache ...".
#
# Mirrors server/helpers/Schema.js's boot verification, so a green run here
# means a green boot there.
#
FAILURES=0
require_object() {
local label="$1" count="$2"
if [ "${count:-0}" -eq 0 ]; then
echo "FAILED: missing $label" >&2
FAILURES=$((FAILURES + 1))
fi
}
require_object "table scrape_cache" "$(sql "SELECT COUNT(*) FROM information_schema.TABLES
WHERE TABLE_SCHEMA='$DB_NAME' AND TABLE_NAME='scrape_cache'")"
for column in scrape_state scrape_attempts enqueued_at; do
require_object "attachment.$column" "$(sql "SELECT COUNT(*) FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA='$DB_NAME' AND TABLE_NAME='attachment' AND COLUMN_NAME='$column'")"
done
require_object "attachment index attachment_scrape_state" "$(sql "SELECT COUNT(*) FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA='$DB_NAME' AND TABLE_NAME='attachment' AND INDEX_NAME='attachment_scrape_state'")"
# Checked by TYPE, not just by name: a BTREE index called attachment_text_index
# would make MATCH..AGAINST return nothing at all, with no error anywhere.
FT=$(sql "SELECT IFNULL(MAX(INDEX_TYPE),'MISSING') FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA='$DB_NAME' AND INDEX_NAME='attachment_text_index'")
if [ "$FT" != "FULLTEXT" ]; then
echo "FAILED: attachment_text_index is '$FT', expected FULLTEXT." >&2
echo "Attachment search depends on MATCH..AGAINST and is now broken." >&2
echo "Attachment search depends on MATCH..AGAINST and would silently return nothing." >&2
FAILURES=$((FAILURES + 1))
fi
if [ "$FAILURES" -gt 0 ]; then
echo "" >&2
echo "$FAILURES required object(s) missing after migrating -- the scraper will stay disabled." >&2
echo "This should not happen; check 'prisma migrate status' and the migration SQL." >&2
exit 1
fi