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
|
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
|
||||||
|
|||||||
Reference in New Issue
Block a user