Sync the self-hosting stack
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user