From f0f0c9dfe09ac11cd7f06a3381d57e93a8b5bd1f Mon Sep 17 00:00:00 2001 From: Luxit Date: Mon, 31 Aug 2026 21:56:10 +0200 Subject: [PATCH] Sync the self-hosting stack --- CHANGELOG.md | 38 +++++++++++++++++--------------------- 1 file changed, 17 insertions(+), 21 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 3024c2d..c17f726 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,35 +11,28 @@ cannot be published without its entry. ## 2026-08-31 — Jarvis can wake itself up, knows what day it is, and can read the web `api 0.102.0` `web 0.125.0` `browser 0.1.0` -**The schema step stops once on the way in — see the upgrade note below.** It is the same guard as -`api 0.101.0`, tripped by a different change. +**The schema step is uneventful for almost everyone** — unlike `api 0.101.0`. Read the upgrade +note below only if you created a scheduled task through the Settings screen this afternoon. -### Taking this build: the schema step stops once again +### Taking this build: what the schema step does -Same guard as `api 0.101.0`, tripped by a different change — and for the same reason it is harmless -here. Reshaping scheduled tasks around the conversation drops the columns the old organization-wide -version needed, and the guard refuses a drop without being told to: +Reshaping scheduled tasks around the conversation drops the columns the organization-wide version +needed. **On almost every instance this passes without stopping**, and that is not luck: the guard +refuses a column drop when the table has rows in it, and `Schedule` is empty on every instance that +upgraded from `0.100.0` or earlier — the table only existed from `0.101.0`, published a few hours +before this. Watched on our own instance: dropped six columns and an enum, no warning, no +intervention. -``` -⚠️ There might be data loss when applying the changes: - • The `Schedule` table will lose columns: kind, autonomy, toolName, assetId, … -Error: Use the --accept-data-loss flag … -``` - -**Nothing of yours is in those columns.** They existed only in `api 0.101.0`, which was published -this afternoon, and only a wake-up created through the removed Settings screen could have filled -them. Check before you take our word for it: +**Read the rest of this only if that table is not empty**, which means you created a scheduled task +through the Settings screen that this release removes: ```sql SELECT count(*) FROM "Schedule"; ``` -If that is 0 — which it is on every instance that upgraded straight from 0.100.0 or earlier — the -migration cannot lose anything. If it is not 0, those rows are wake-ups you created today and they -will be dropped; note down what they were before you continue, and recreate them by asking Jarvis -inside the conversation you want them in. - -Then let it through **once**, and put the guard back: +If it returns anything but 0, the migration will refuse and print what it would destroy. Those rows +are wake-ups you made today; note down what they were, then let it through **once** and put the +guard back: - **compose** — set `SCHEMA_ACCEPT_DATA_LOSS=true` in `.env`, `docker compose up -d`, wait for the api, then remove the line. Leaving it set would let a genuinely destructive change through @@ -47,6 +40,9 @@ Then let it through **once**, and put the guard back: - **Kubernetes** — set the same variable on the `jarvis-migrate` Job, run it to completion, then take it off. The api pods keep serving the old build while the Job fails, so there is no outage. +Then recreate them by asking Jarvis inside the conversation you want them to run in — which is where +they now live. + ### Scheduled tasks are now part of a conversation `api 0.101.0` shipped these a few hours ago as an organization-wide screen, and that was the wrong