From 70db57d367e918c6bd476f0acdfbb27c7b112685 Mon Sep 17 00:00:00 2001 From: Luxit Date: Mon, 31 Aug 2026 16:50:53 +0200 Subject: [PATCH] Sync the self-hosting stack --- CHANGELOG.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index c04a7ba..01ac1b4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,44 @@ Two capabilities, and both are about the half of managed services that does not conversation: the work that is on a calendar, and the half of Microsoft 365 that Graph does not reach. +**The schema step stops once on the way in — see the upgrade note directly below.** + +### Taking this build: the schema step stops once, on purpose + +**Read this before you pull.** The migration refuses the first time and says so, and on compose that +leaves the API down until you act. It is not a bug and there is nothing wrong with your data — it is +the data-loss guard doing its job over a change that happens to be harmless. + +You will see: + +``` +⚠️ There might be data loss when applying the changes: + • A unique constraint covering the columns [scheduleId,scheduledFor] on the table + Task will be added. If there are existing duplicate values, this will fail. +Error: Use the --accept-data-loss flag … +``` + +The guard cannot know that the constraint is harmless; it only knows a unique index _could_ fail on +existing duplicates. **The `Task` table has never had anything writing to it** — it was a placeholder +until this release gave it a producer — so on any instance upgrading from an earlier build it is +empty, and adding the index to an empty table cannot lose anything. Check it yourself if you would +rather not take our word for it: + +```sql +SELECT count(*) FROM "Task"; -- expected: 0 +``` + +Then let it through **once**, and put it back afterwards: + +- **compose** — set `SCHEMA_ACCEPT_DATA_LOSS=true` in `.env`, `docker compose up -d`, wait for the + api to come up, then remove the line again. Leaving it set would let a genuinely destructive + schema change through unannounced on some future release. +- **Kubernetes** — set the same variable on the `jarvis-migrate` Job, run it to completion, then + take it back off. The API pods keep serving the old build while the Job fails, so there is no + outage — the rollout simply waits. + +If that query returns anything other than 0, stop and ask before forcing it. + ### Scheduled work Everything Jarvis did until now happened inside the turn that asked for it. That is right for an