Sync the self-hosting stack

This commit is contained in:
2026-08-31 16:50:53 +02:00
parent 51538252c2
commit 70db57d367
+38
View File
@@ -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 conversation: the work that is on a calendar, and the half of Microsoft 365 that Graph does not
reach. 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 ### Scheduled work
Everything Jarvis did until now happened inside the turn that asked for it. That is right for an Everything Jarvis did until now happened inside the turn that asked for it. That is right for an