R1: Migration 0010 now writes revision 0 into every ground_dinner job payload that has none. Jobs queued before the upgrade carry only dinner_id, so the boot cleanup, which matches a pending dinner to its job by revision, failed those dinners as interrupted while their jobs were still queued. The migration runs before the job runner starts. A new test migrates a database to 0009, adds a pending Regular with a legacy queued job, upgrades and boots, and checks the dinner stays pending and is then grounded. R2: Archiving a dinner, or renaming a pending one, now cancels the grounding of any ground_dinner job running for it at an older revision, so no further search, page fetch, photo download or model call is made. The job is registered before it reads the dinner, so an archive or rename committed after that read always finds it. A stopped job succeeds and reports the dinner's current grounding status. The archive and rename tests now check that the job ends while its search is still held, with no page fetched and no model call for the stale name. R3: gen_folds.py writes web/src/dinners/letterFolds.json from the same table as folds_table.go, and names.ts folds through it instead of a hand-copied subset. names.ts also lowercases letter by letter, as Go's strings.ToLower does, rather than by context. TestLetterFoldsMatchPWA fails when the two tables differ. The shared cases add "Ƈhili", "Ꞔarbanzo Stew" and "ΜΟΥΣΑΚΑΣ" (final sigma). Maestro task 5037ff86-181d-448e-927b-c2fd2258a25d. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
17 lines
869 B
SQL
17 lines
869 B
SQL
-- 0010_dinner_grounding_revision: each ground_dinner job carries the
|
|
-- dinner's grounding_revision when it was enqueued, and records its result
|
|
-- only while the dinner still has that revision. Renaming a pending dinner
|
|
-- raises the revision before enqueuing the job for the new name, so an
|
|
-- earlier job — queued or running — can no longer write the dinner.
|
|
|
|
ALTER TABLE dinners ADD COLUMN grounding_revision INTEGER NOT NULL DEFAULT 0;
|
|
|
|
-- Every dinner starts at revision 0, so a ground_dinner job enqueued
|
|
-- before this migration, whose payload has only dinner_id, is for revision
|
|
-- 0. Recording it lets the boot cleanup, which matches a pending dinner to
|
|
-- its job by revision, see a job still queued for its dinner.
|
|
UPDATE jobs
|
|
SET payload = json_set(payload, '$.revision', 0)
|
|
WHERE kind = 'ground_dinner'
|
|
AND json_type(payload, '$.revision') IS NULL;
|