admin/felhom.eu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

R-459 CLOSED (MariaDB converts itself, proven by harness + live), golden 0.236.0 (R-467), the golden waiver (R-468)

Browse Source 
Operator rulings 2026-09-13, both shipped the same day:
- MariaDB finishes its own conversion (catalog eec1228/bd32830/3525e35). Harness E3/E3b `proven`
  with engine_state_after "already upgraded to 12.3.3-MariaDB [exit=1]", the skip line gone, C3
  still `failed`; landed on demo-hp through the real 15-min cycle, nothing recreated, one deliberate
  restart logged "MariaDB upgrade not required" with the app serving. Evidence:
  documentation/audits/r459-close-2026-09-13/. The engine-major rule + gate keep every engine
  inside its major until Slice 4 (R-448) — removal tracked as R-469.
- Goldens on a cadence, not per release. golden_currency_gate.py reads a dated waiver
  (documentation/tests/golden-waiver.yml, <= 14 days, row-bound): valid + BEHIND -> loud advisory,
  exit 0; expired -> red again naming the date; UNRECORDED (R-385) never covered; malformed -> 2,
  never 0. Tests cases 5-15 incl. the R-421 decoy; red-proof old-vs-new on the real behind tree.
  R-242's vouch half stays open. Cadence in RUNBOOK-manual-build.md §4.2 + the checklist.
- Golden 0.236.0 baked, round-tripped, vouched, floor raised 0.232.0 -> 0.236.0
  (documentation/tests/golden-0.236.0-2026-09-13/) — the last per-release bake; the waiver was
  issued AFTER it landed. No --no-verify anywhere in this session.

Rows: R-459 CLOSED, R-467 CLOSED, R-242 narrowed; R-468/R-469/R-470/R-471 opened. 09 §3 gains
decisions 5 and 6; STATUS items 11 and 12 closed; CONTEXT records the cadence ruling.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
This commit is contained in:
authentik Default Admin
2026-09-13 10:14:37 +02:00
parent 4b2e5608c2
commit ae59c31a84
62 changed files with 2607 additions and 220 deletions
Download Patch File Download Diff File Expand all files Collapse all files
STATUS.md
+32 -66
View File
@@ -1,5 +1,11 @@
# STATUS — what works, what's broken, what's next
**Updated 2026-09-13 (second pass) — you decided both open items. The database engine now finishes
its own conversion on the four MariaDB apps; the upgrade machine proved it and it landed on the HP
without a ripple. Goldens are now weekly and before any install, not per release, and the gate
knows: it reads a dated permission slip that runs out after 14 days. Today's golden (0.236.0) is
baked and live. Nothing needs you.**
**Updated 2026-09-13 — "delete my data too" now deletes the data, or tells you it could not. Until today the box said it worked and left everything on the drive. Live on both machines (0.236.0), proven on the HP with a throwaway Nextcloud. Nothing needs you. Item 7 is closed: you decided it on 2026-09-02 and the page still listed it open.**
**Updated 2026-09-06 (third pass) — I chased down the BookStack database problem I found this
@@ -205,73 +211,22 @@ nothing.*
version and look unwell when it is fine. **It cannot lose data — the worst case is a false
alarm.** Freezing that file too would break the „Frissítés elérhető" label, which is a worse trade.
11. **How wide should I take the upgrade testing? This is the one decision from today, and it is
about money and time, not about safety.**
11. ~~**How wide should I take the upgrade testing?**~~ **DECIDED 2026-09-13: as wide as possible,
through the nightly unattended sessions.** Every app gets its turn as the nightly rotation reaches
it, one hand-written way in per app. The apps that can only be reached through a browser wait for
the sessions that run on your Windows machine with Chrome, where the machine can click. Written
into the update architecture as decision 6. **Nothing to do.**
**What I built.** A machine that installs an app, puts real data in through the app's own front
door, upgrades it, and then asks the app for the data back. Not "did it start" — the box has
already fooled us that way once.
**I also taught it to fail.** Before believing anything, I pointed it at an upgrade I knew was
broken. It came back red. That is why I trust the greens.
**What it found, on three apps and five real upgrades.**
- **The data survived every single time.** That is the good news and it is worth having.
- **Whether an upgrade can be UNDONE depends on the app, not on upgrades.** Docmost will not go
back — the old version refuses to start on the changed data. PrivateBin goes back fine. **We
had been assuming one answer for all 53 apps. There isn't one.**
- **And it found a real problem in our own BookStack setup.** Our template moves the database
engine to a new major version, and the engine says, in its own words, that the conversion it
needs is being *skipped*. It works today. **I did not measure whether it ever breaks**, and I
am not going to guess.
**The decision: how many of the 53 apps do I test?**
- **Only the apps that keep data in a database (~25).** Today's run showed the undo question only
ever bites there. **Cost: roughly a day of my time.**
- **All 53.** Complete, and it gives us a list nobody has. **Cost: several days**, and the reason
is not the machines — it is that **each app needs its own hand-written way in**, and that work
does not get cheaper the more you do. Two of today's three needed one, and one of them took two
attempts.
**My pick: the database ones first.** It answers the question that changes the product, and if it
goes well the rest is a decision you can take later with better numbers.
**If you do nothing:** nothing breaks. The machine is built and committed, so it does not go
stale, and the BookStack problem is written down and waiting either way.
12. **Shall I tell the database engine to finish its own conversion? One yes/no. It affects four
apps and I have measured both sides.**
**The background, in one line.** This morning I found that when BookStack's database engine moves
to a new major version, the engine says the conversion it needs is being **skipped** — and then
works anyway.
**What I measured this afternoon.**
- **It does not get worse.** I restarted it five times. The app answered correctly all five
times, and nothing changed for the worse.
- **But it never fixes itself either.** Every single time it starts, the engine says the check is
still needed. It will say that forever.
- **Fixing it takes seven seconds.** The engine backs itself up first, does the conversion, done.
- **And the catch I was worried about is not there.** I expected that converting properly would
mean we could no longer go back to the old version. **We still can** — I tried it, and the app
came back with its data.
**So this is not the difficult trade I thought I would be bringing you. It is a cheap tidy-up.**
- **Yes, turn it on.** Four apps get a correctly-converted database — BookStack, Kimai, Nextcloud
and RomM. Costs seven seconds the one time each of them moves a major version. **This is what I
would do.**
- **No, leave it.** Nothing breaks today. The engine keeps saying it wants a check, on every
start, indefinitely.
**One honest limit on my "yes".** I proved the app's normal use keeps working. I did **not** test
every database feature on an unconverted engine — so I can tell you it has not broken, not that
nothing can. That is exactly why leaving it alone is a real choice and not just laziness.
**If you do nothing:** nothing breaks and nothing is at risk this week. Only BookStack has
actually moved a major version so far; the other three will land in the same place when their
turn comes. I have not changed any template — this is your call, not a quiet edit.
12. ~~**Shall I tell the database engine to finish its own conversion?**~~ **DECIDED YES 2026-09-13,
and shipped the same day.** The four MariaDB apps — BookStack, Kimai, Nextcloud, RomM — now carry
one setting that lets the engine convert its own files when it moves to a new major version.
Seven seconds, and it backs itself up first. **Proven before it shipped:** the upgrade machine
re-ran the BookStack edge and this time the engine says, in its own words, that it is already
upgraded — the "skipped" line is gone, and the data read back afterwards. **Watched as it landed:**
the change reached the HP on the normal 15-minute cycle, nothing restarted by itself, and one
deliberate restart came back clean with the app serving. **The rule until the next piece is built:**
the Update button still takes no backup, so no app may move a database engine across a major
version until it does — a gate refuses such a change at push time. **Nothing to do.**
13. **"Delete my data too" now deletes the data — or tells you it could not.** Until today, when a customer removed an app and ticked the box, the box said it worked and left everything on the drive (128 MB of a Nextcloud on 2026-09-01). The cause: the removal asked one global setting for the drive, and no machine fills that setting in. Every other part of the box already asks the app itself where its data is. Now the removal does too. If the box cannot work out where the data is, it refuses and keeps the app, so you can try again — it never again reports success over data left behind. Proven on the HP with a throwaway Nextcloud: 63 MB the app wrote itself was gone after removal, and the answer listed it; the refusal was shown with the app still in place; an app with no drive data gets a plain "nothing to delete" note. Live on both machines (0.236.0). No standing app was touched. **If you do nothing:** nothing to do.
@@ -281,6 +236,17 @@ nothing.*
## Decided — and what would reopen each
- **GOLDENS ARE NOW WEEKLY AND BEFORE ANY INSTALL, NOT PER RELEASE — AND THE GATE KNOWS. DECIDED 2026-09-13.**
In August I baked 25 goldens in 26 days, almost one per release, because the check trips on every
release on purpose. From today: one golden a week, and always before a drill or a fresh install.
Every release still reaches both demo machines in about 20 seconds — only the image a **new**
machine starts from moves to a cadence. The check now reads a dated permission slip that runs out
after at most 14 days; while it is valid the check warns instead of refusing, and when it runs out
the check is red again until someone bakes or renews. A dated slip cannot be forgotten — it just
expires. Today's golden (0.236.0) is baked, checked three ways, and live.
**Reopens if:** the first outside customer installs (the slip is retired then), or a fresh install
ever lands on a golden older than the week.
- **THE BACKUP AND RESTORE WORK IS FINISHED FOR BETA. DECIDED 2026-09-01.**
**What is done, and proven on the real machines:** everything **you or a customer** does alone —
getting deleted files back, getting an app's data back, getting a whole app back, and losing a