ReviewOS

theopenfarm/openfarm.ing

fix: recover demo catalog identities after native soft deletion

#40
Closed chris opened this 11 days ago ·
11 days ago

PR #39 is merged at 7dc69d4d80a60a748b34538c5ef436c90d33d0b8. Its exact PR CI passed all applicable jobs, including 113 tests, types, lint/docs and the full frontend build. Main CI software checks also pass, but deployment 40141524843 fails in the owned catalog:sync preStart command with UNIQUE constraint failed: farms.slug.

The maintained ORM now honors the Farm and Field soft-delete traits. The old publisher deletes the demonstration farm and field, then recreates their globally unique slugs. The hidden rows still own those slugs. The failed deployment already created a native database backup; retain it and investigate any published imagery metadata before claiming recovery. The deployed server also used Bun 1.4.2 despite the app/CI 1.4.4 requirement, and migration output reported a legacy polymorphic-table column error. Do not hide those observations or call deployment qualified until resolved or scoped explicitly.

Acceptance:

  • Reproduce the first/repeated CLI publication and tombstone case with the actual released native ORM and an isolated SQLite database, proving the database path before mutation.
  • Fix the owning application publisher to reuse and restore its reserved demo identities; preserve stable IDs, published imagery metadata and customer holdings/data. Refuse demo slug/callsign ownership conflicts before destructive work.
  • Test first run, repeat, soft-deleted demo recovery, imagery preservation and unrelated customer records. Keep original failures and use native model/query APIs rather than dependency patches or production SQL edits.
  • Verify the deployment runtime requirement at its owning source/config, without bypassing version checks or patching installed packages.
  • Pass native lint/types/full app tests, independent reviews and exact CI. Publish as Chris without coauthors with a normal fast-forward to main, then verify actual deployment/public marketing/auth/docs responses.

The earlier cold function-barrel issue #37 is fixed in source. This follow-up tracks the newly exposed persistence/deployment behavior. Auth link activation remains separately tracked in #38. No account, mail, push or physical output behavior is qualified by these software checks.

11 days ago

Recovery source and qualification update:

  • The catalog command now preserves stable demo identities, restores reserved soft-deleted records, retains published imagery metadata, and rejects customer-owned identifier conflicts before catalog changes. Its real SQLite/CLI regression passed 40 assertions. The native application suite passed 114 tests and 3,549 assertions. Both source reviews are clean.
  • A read-only inspection of the retained pre-deployment backup confirmed that the affected demo mission's three imagery fields were already null. No production customer records have been edited during this investigation.
  • The application runtime configuration uses an isolated Bun1.4.4 installed by the published ts-pantry0.11.126 SDK. A fresh private install was qualified on the actual old-runtime host without replacing its shared Bun. The published cloud SDK also passed local configuration qualification for both absolute service executable paths.
  • The owning framework fixes are typed soft-delete restoration, native bounded process output, and legacy trait pivot repair and migration failure propagation. The pivot change passed 79 focused native tests and 366 assertions, including default failures and fresh-command opt-outs. Its exact CI is still running.
  • The deployment documentation builds successfully. Released-framework adoption, removal of the existing migration-error suppression, final consumer qualification, and the recovery deployment remain pending. The source fixes will be consumed through the native release workflow, without installed-package patches.

This issue stays open until the released dependency graph, deployment, and production readback are verified.

11 days ago

Recovery is deployed from main 110992205bd21e7515032468938cffd89e0e56f6 via PR #41. Exact PR CI and main CI/deployment pass. Local full native suite: 114 pass, 0 fail, 3,564 assertions; types/lint/docs and independent review axes pass.

Pinned-host read-only verification confirms main/API/docs release1109922. Main/API real processes and bare children use private Bun1.4.4, actual Stacks0.75.301/ORM0.75.301/PantrySDK126/STX687/BunPress25. Global host Bun remains1.4.2.

Native deployment backup 2026-10-25T04-03-13-720.sqlite.sqlite is retained. Farm89 and field98 are active again, with98 demo detections and1treatment map. All7 protected customer-data groups have identical counts and complete-row hashes versus that immediate backup. The prior failed deployment had already deleted demo aircraft91, so the corrected publisher created92; it does not claim to restore a row that no longer existed. All3imagery metadata fields were alreadyNULL in the earlier original backup and remainNULL, so no imagery recovery is claimed. Missing taggable_id was repaired by native migration, NOTNULL/noDEFAULT; no manualproductionSQL.

Actual deployed marketing capability/auth navigation passes desktop and320pxkeyboard, with correctdestinationURL/h1/title/mainfocus and nooverflow/errors. Fieldreport and docsimplementationroadmap/searchAirframes pass. The same frozen native301consumer passes the authsequence privately. No accounts/provider/mail/booking actions submitted.

Separately, native ts-cloud still starts the generated scheduler on the host runtime. Owning source follow-up: stacksjs/ts-cloud#197. SPA canonical/description remains separately tracked inSTX#2121. These checks do not qualify physical flights, scheduled treatment or provider delivery.

Sign in to comment on this issue.