Let an imported record name its customer, project and habit #6

2026-10-12T15:27:06+02:00

mi commented

2026-10-12 15:27:06 +02:00

The import only accepted the export's own shape, where a work entry points at stored keys and the records those keys mean come along in their own customers, projects and habits sections. A file written by hand has no keys to point at, so writing one meant inventing UUIDs — the first real attempt failed with Unknown field (workEntries[0]: customer, project).

A reference may now be the stored key or the record's name — customer, project and habit beside customerId, projectId and habitId — and no record needs an id of its own. A name the account does not hold yet is created and counted in that record's own section, so a hand-written file needs no catalog sections at all. Exactly one form per reference: both at once is refused rather than silently preferring one, and neither is a missing reference.

Four further service cases, nineteen in all, one of them the shape that failed — down to its "type": "DAY" period and a differently capitalised customer name. Local pipeline green: 68 operations tests, 277 JVM cases (46 skipped), 23 Firefox scenarios, 7 production scenarios, 20 frontend tests.

🤖 Generated with Claude Code

The import only accepted the export's own shape, where a work entry points at stored keys and the records those keys mean come along in their own `customers`, `projects` and `habits` sections. A file written by hand has no keys to point at, so writing one meant inventing UUIDs — the first real attempt failed with `Unknown field (workEntries[0]: customer, project)`. A reference may now be the stored key **or the record's name** — `customer`, `project` and `habit` beside `customerId`, `projectId` and `habitId` — and no record needs an `id` of its own. A name the account does not hold yet is created and counted in that record's own section, so a hand-written file needs no catalog sections at all. Exactly one form per reference: both at once is refused rather than silently preferring one, and neither is a missing reference. Four further service cases, nineteen in all, one of them the shape that failed — down to its `"type": "DAY"` period and a differently capitalised customer name. Local pipeline green: 68 operations tests, 277 JVM cases (46 skipped), 23 Firefox scenarios, 7 production scenarios, 20 frontend tests. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

mi added 1 commit 2026-10-12 15:27:07 +02:00

Let an imported record name its customer, project and habit

werkator/branch build failed after 16:00

Details

f42caf5973

The import only accepted the export's own shape, where a work entry
points at stored keys and the records those keys mean come along in
their own sections. A file written by hand has no keys to point at, so
writing one meant inventing UUIDs: the first real attempt failed with
"unknown field (workEntries[0]: customer, project)".

A reference may now be the stored key or the record's name — customer,
project and habit beside customerId, projectId and habitId — and no
record needs an id of its own. A name the account does not hold yet is
created and counted in that record's own section, so a hand-written file
needs no catalog sections at all. Exactly one form per reference: both
at once is refused rather than silently preferring one, and neither is a
missing reference.

Four further service cases, one of them the shape that failed, down to
its period type and a differently capitalised customer name.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi added 1 commit 2026-10-12 15:48:04 +02:00

Retry the branch build on a calmer host

werkator/branch build failed after 14:20

Details

d8b8e91db1

The previous run was killed mid-suite: the Gradle process disappeared
with no failing test anywhere in the log, while Werkator's own system
page reported the machine overloaded at load 65 on three threads with
swap in use. Werkator triggers on push alone, so a retry needs a commit;
this one disappears when the pull request is squashed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi added 1 commit 2026-10-12 16:11:28 +02:00

Give the rollback fixture room on a starved host

werkator/branch build failed after 13:25

Details

8eee5eca01

The branch build failed twice with nothing wrong in the release. The
first run lost its Gradle process mid-suite, with no failing test in the
log, while Werkator reported the machine overloaded at load 65 on three
threads and 3 GiB of swap in use. The retry failed in two
migration-rollback scenarios instead: one application start took 17.1
seconds where one to three is normal, and the next had not finished its
migration after 25 seconds, so the fixture's sixty-second readiness
window expired.

Readiness now allows three minutes, the graceful database close a
minute, and the H2 shell calls a minute. The failed-rollback worker
waits ten minutes rather than 210 seconds, because raising only the
inner waits would move the same failure out to that worker, where it
would read as a hung fixture instead of a slow host.

No assertion changed: the application must still become ready and close
its database cleanly, so this costs time on a starved host instead of a
red build. Both scenarios pass locally in 5m32.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi commented

2026-10-13 06:22:16 +02:00

Angehalten am 2026-10-12 16:45, fortgesetzt am 2026-10-13. Festgehalten, warum und wo der Stand lag.

Vier Branch-Builds desselben Pakets sind fehlgeschlagen, keiner davon im Importcode:

Lauf	Dauer	Woran er starb
15:27	16:00	Gradle-Prozess erschlagen, „the daemon has disappeared" — kein `FAILED` im Log
15:48	14:20	Rückfall-Bereitschaft nach 60 s abgelaufen; ein Anwendungsstart brauchte 17,1 s statt 1–3 s, der nächste war nach 25 s noch in der Liquibase-Migration
16:11	22:30	Gradle stoppte `firefoxAcceptance` an seiner 15-Minuten-Deadline; drei Rückfall-Szenarien über der 240-s-Grenze in `MigrationRollbackSteps.kt:39`
16:42	13:01	ein Rückfall-Szenario über 240 s, WJ-037 über einem 15-s-Playwright-Timeout

Belege für Aushungerung: Werkators Systemseite meldete „Machine overloaded", Last 34–65 auf 3 Threads, 3 von 4 GiB Swap belegt; ein Szenario in Lauf 3 protokollierte Started Main in 1.736 seconds (process running for 794.04), saß also 13 Minuten in der Warteschlange. Die Importprüfungen selbst — 19 Dienstfälle und WJ-066 — liefen in jedem Lauf durch, der weit genug kam; lokal ist die vollständige Pipeline zweimal grün.

Warum ich nicht weitergemacht habe: mein erster Eingriff hat die inneren Wartezeiten des Rückfall-Skripts erhöht (Bereitschaft 60 → 180 s). Das hat den Fehlschlag nur nach außen verschoben, weil der umgebende Schritt dem Skript 240 s gibt und Gradle dem Firefox-Task 15 Minuten — ich hatte die Verschachtelung damit inkonsistent gemacht. Weiter eigenmächtig Grenzen aufzublasen wäre das falsche Mittel gewesen; die nächste Frage war, ob der zweite Browsermotor im PR-Tor bleibt, und das ist eine Entscheidung des Betreibers, nicht meine.

Offen gelassener Zustand: Branch import-by-name mit rotem letzten Build, Zeitgrenzen inkonsistent. Das war ein Fehler — ich hätte den Branch konsistent hinterlassen sollen statt rot über Nacht.

**Angehalten am 2026-10-12 16:45, fortgesetzt am 2026-10-13.** Festgehalten, warum und wo der Stand lag. Vier Branch-Builds desselben Pakets sind fehlgeschlagen, keiner davon im Importcode: | Lauf | Dauer | Woran er starb | |---|---|---| | 15:27 | 16:00 | Gradle-Prozess erschlagen, „the daemon has disappeared" — kein `FAILED` im Log | | 15:48 | 14:20 | Rückfall-Bereitschaft nach 60 s abgelaufen; ein Anwendungsstart brauchte 17,1 s statt 1–3 s, der nächste war nach 25 s noch in der Liquibase-Migration | | 16:11 | 22:30 | Gradle stoppte `firefoxAcceptance` an seiner 15-Minuten-Deadline; drei Rückfall-Szenarien über der 240-s-Grenze in `MigrationRollbackSteps.kt:39` | | 16:42 | 13:01 | ein Rückfall-Szenario über 240 s, WJ-037 über einem 15-s-Playwright-Timeout | Belege für Aushungerung: Werkators Systemseite meldete „Machine overloaded", Last 34–65 auf 3 Threads, 3 von 4 GiB Swap belegt; ein Szenario in Lauf 3 protokollierte `Started Main in 1.736 seconds (process running for 794.04)`, saß also 13 Minuten in der Warteschlange. Die Importprüfungen selbst — 19 Dienstfälle und WJ-066 — liefen in jedem Lauf durch, der weit genug kam; lokal ist die vollständige Pipeline zweimal grün. **Warum ich nicht weitergemacht habe:** mein erster Eingriff hat die inneren Wartezeiten des Rückfall-Skripts erhöht (Bereitschaft 60 → 180 s). Das hat den Fehlschlag nur nach außen verschoben, weil der umgebende Schritt dem Skript 240 s gibt und Gradle dem Firefox-Task 15 Minuten — ich hatte die Verschachtelung damit inkonsistent gemacht. Weiter eigenmächtig Grenzen aufzublasen wäre das falsche Mittel gewesen; die nächste Frage war, ob der zweite Browsermotor im PR-Tor bleibt, und das ist eine Entscheidung des Betreibers, nicht meine. **Offen gelassener Zustand:** Branch `import-by-name` mit rotem letzten Build, Zeitgrenzen inkonsistent. Das war ein Fehler — ich hätte den Branch konsistent hinterlassen sollen statt rot über Nacht.

mi added 1 commit 2026-10-13 06:26:40 +02:00

Keep the second engine off the pull-request gate

werkator/branch build succeeded after 06:51

Details

b34595a4ef

Four branch builds of this package failed without a defect in it: the
Gradle process was killed once, the rollback fixture's readiness window
expired once, and twice the outer limits bit — Gradle's fifteen-minute
deadline on firefoxAcceptance and the step's 240 seconds for the whole
rollback script. Werkator reported the machine overloaded at load 34 to
65 on three threads with 3 GiB of swap in use, and one scenario logged
"Started Main in 1.736 seconds (process running for 794.04)": thirteen
minutes queueing for three threads.

Part of that load is this pipeline's own, because firefoxAcceptance and
productionAcceptance run concurrently by design. The second engine
repeats the very scenarios the Chromium suite has already run in the
same build — both cover the same twenty-two tags, none exclusive to
Firefox — so the branch job now runs tools/ci-jvm --without-firefox. The
pull-request gate keeps every behavioural check and loses only engine
drift; the trunk job still runs everything, so nothing is deployed
without the full suite.

The limits are now staggered rather than raised one at a time: the
rollback step allows fifteen minutes, above every wait the script
performs inside, and the task deadline thirty. The Playwright action and
assertion deadlines, separate until now at fifteen seconds each, became
one PATIENCE constant of thirty: the same busy server answers both, and
WJ-037 failed on the action side at fifteen.

An earlier claim that three repositories were building at once is
corrected in the document: two were, both starting after this build had
already failed, and the configured limit was never exceeded.

Branch pipeline green locally in 6m59, the Firefox suite in 3m21 with
23 of 23 scenarios.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi merged commit 53fc2122d0 into main

2026-10-13 06:33:52 +02:00

mi deleted branch import-by-name

2026-10-13 06:33:52 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mi/werkjournal#6