Sporadisch scheiternde Browser-Szenarien als eigenen Knoten führen #15

2026-10-23T20:19:55+02:00

claude-code commented

2026-10-23 20:19:55 +02:00

Am 2026-10-23 scheiterte der Branch-Build zu werkjournal PR#14 an WJ-059 („Recover a work draft from a closed tab"). Derselbe Baum — --amend ohne inhaltliche Änderung, Force-Push — lief beim zweiten Anlauf grün. Lokale Wiederholungen desselben Commits scheiterten an zwei anderen Szenarien aus dem Habit-Bereich, und ein vollständiger lokaler Lauf war grün.

Wechselnde Szenarien, keine inhaltliche Gemeinsamkeit, keine Beziehung zur jeweiligen Änderung.

Warum das einen eigenen Knoten verdient

Das PR-Tor ist damit in beide Richtungen unzuverlässig: ein grüner Lauf belegt nicht, dass eine Änderung trägt, und ein roter nicht, dass sie bricht. Jeder Fehlschlag kostet eine Untersuchung, die am Ende nichts über die Änderung aussagt — in dieser Session zweimal.

Der Werkbaum kannte die Lastempfindlichkeit der Pipeline bisher nur als Laufzeitthema: #pipeline-duration, #rollback-timeouts (Zeitgrenzen an einen überlasteten Host angepasst), #branch-gate-engines und #branch-gate-recheck. Dass einzelne Szenarien unter Last sporadisch scheitern, war nirgends erfasst.

Eine Ausnahme gibt es bereits, aber sie ist eng: #habit-month-date-independent hielt am 2026-10-03 fest, dass ein Szenario vom laufenden Datum abhing. Das war eine konkrete, behobene Ursache in einem Szenario — kein Knoten für das allgemeine Muster.

Was der Knoten festhält

#browser-flakiness steht offen unter #operations, neben #pipeline-duration, mit Verweis auf #branch-gate-engines. Er nennt die drei zu prüfenden Richtungen:

Zeitgrenzen gegen eine langsame Antwort — dann sind die Zusicherungen zu ungeduldig.
Gemeinsamer Zustand zwischen Szenarien — dann fehlt Isolation.
Playwright-Aktionen gegen noch nicht fertige Vaadin-Updates — dann warten die Schritte auf das falsche Ereignis.

Ausdrücklich festgehalten ist, die Sache nicht durch eine Wiederholungsautomatik zu verdecken, ehe die Ursache bekannt ist: eine Wiederholung versteckt genau die Information, die hier fehlt.

Was dieser PR nicht tut

Keine Untersuchung, keine Behebung, kein Code — nur der Plan und die Version. Die Beobachtung ist belegt, die Ursache nicht; den Knoten jetzt anzulegen hält fest, was sonst mit dieser Session verloren geht.

Nachweise

JAVA_HOME=~/opt/jdk25 ./tools/ci-jvm --without-firefox grün: BUILD SUCCESSFUL in 7m 32s, 72 Betriebstests. Version 0.1.128-SNAPSHOT.

Dass dieser grüne Lauf nach dem eigenen Knoten nur begrenzt beweist, ist mir bewusst.

🤖 Generated with Claude Code

Am 2026-10-23 scheiterte der Branch-Build zu [werkjournal PR#14](https://git.javagil.de/mi/werkjournal/pulls/14) an WJ-059 („Recover a work draft from a closed tab"). Derselbe Baum — `--amend` ohne inhaltliche Änderung, Force-Push — lief beim zweiten Anlauf grün. Lokale Wiederholungen desselben Commits scheiterten an zwei **anderen** Szenarien aus dem Habit-Bereich, und ein vollständiger lokaler Lauf war grün. Wechselnde Szenarien, keine inhaltliche Gemeinsamkeit, keine Beziehung zur jeweiligen Änderung. ## Warum das einen eigenen Knoten verdient Das PR-Tor ist damit in beide Richtungen unzuverlässig: ein grüner Lauf belegt nicht, dass eine Änderung trägt, und ein roter nicht, dass sie bricht. Jeder Fehlschlag kostet eine Untersuchung, die am Ende nichts über die Änderung aussagt — in dieser Session zweimal. Der Werkbaum kannte die Lastempfindlichkeit der Pipeline bisher nur als **Laufzeitthema**: `#pipeline-duration`, `#rollback-timeouts` (Zeitgrenzen an einen überlasteten Host angepasst), `#branch-gate-engines` und `#branch-gate-recheck`. Dass einzelne Szenarien unter Last sporadisch *scheitern*, war nirgends erfasst. Eine Ausnahme gibt es bereits, aber sie ist eng: `#habit-month-date-independent` hielt am 2026-10-03 fest, dass ein Szenario vom laufenden Datum abhing. Das war eine konkrete, behobene Ursache in einem Szenario — kein Knoten für das allgemeine Muster. ## Was der Knoten festhält `#browser-flakiness` steht offen unter `#operations`, neben `#pipeline-duration`, mit Verweis auf `#branch-gate-engines`. Er nennt die drei zu prüfenden Richtungen: - **Zeitgrenzen gegen eine langsame Antwort** — dann sind die Zusicherungen zu ungeduldig. - **Gemeinsamer Zustand zwischen Szenarien** — dann fehlt Isolation. - **Playwright-Aktionen gegen noch nicht fertige Vaadin-Updates** — dann warten die Schritte auf das falsche Ereignis. Ausdrücklich festgehalten ist, die Sache **nicht durch eine Wiederholungsautomatik zu verdecken**, ehe die Ursache bekannt ist: eine Wiederholung versteckt genau die Information, die hier fehlt. ## Was dieser PR nicht tut Keine Untersuchung, keine Behebung, kein Code — nur der Plan und die Version. Die Beobachtung ist belegt, die Ursache nicht; den Knoten jetzt anzulegen hält fest, was sonst mit dieser Session verloren geht. ## Nachweise `JAVA_HOME=~/opt/jdk25 ./tools/ci-jvm --without-firefox` grün: `BUILD SUCCESSFUL in 7m 32s`, 72 Betriebstests. Version 0.1.128-SNAPSHOT. Dass dieser grüne Lauf nach dem eigenen Knoten nur begrenzt beweist, ist mir bewusst. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-code added 1 commit 2026-10-23 20:19:55 +02:00

Sporadisch scheiternde Browser-Szenarien als eigenen Knoten führen

werkator/branch build succeeded after 07:18

Details

58f272364f

Am 2026-10-23 scheiterte der Branch-Build zu PR#14 an WJ-059 („Recover a work draft from a closed
tab"); derselbe Baum lief beim zweiten Anlauf grün. Lokale Wiederholungen desselben Commits
scheiterten an zwei anderen Szenarien aus dem Habit-Bereich, ein vollständiger lokaler Lauf war
grün. Wechselnde Szenarien, keine inhaltliche Gemeinsamkeit, keine Beziehung zur jeweiligen
Änderung.

Das macht das PR-Tor unzuverlässig in beide Richtungen: ein grüner Lauf belegt nicht, dass eine
Änderung trägt, und ein roter nicht, dass sie bricht. Jeder Fehlschlag kostet eine Untersuchung, die
nichts über die Änderung aussagt. Der Werkbaum kannte die Lastempfindlichkeit der Pipeline bisher nur
als Laufzeitthema (#rollback-timeouts, #branch-gate-engines, #branch-gate-recheck); dass einzelne
Szenarien sporadisch scheitern, war nirgends erfasst.

#browser-flakiness steht als offener Knoten unter #operations, neben #pipeline-duration, und nennt
die drei zu prüfenden Richtungen: zu ungeduldige Zusicherungen, fehlende Isolation zwischen
Szenarien, oder Playwright-Aktionen gegen noch nicht fertige Vaadin-Updates. Ausdrücklich
festgehalten ist, die Sache nicht durch eine Wiederholungsautomatik zu verdecken, ehe die Ursache
bekannt ist — eine Wiederholung versteckt genau die Information, die hier fehlt.

Nur Plan und Version, kein Code.

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

mi approved these changes

2026-10-23 22:27:30 +02:00

Dismissed

mi approved these changes

2026-10-24 22:21:10 +02:00

mi merged commit 96a96ba866 into main

2026-10-24 22:21:31 +02:00

mi deleted branch browser-flakiness

2026-10-24 22:21:31 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mi/werkjournal#15