LibreKAT/Ocideck
LibreKAT/Ocideck
Watch
4
0
Fork
You've already forked Ocideck
 0
Code Issues 2 Pull requests Projects Releases 4 Packages Activity Actions 5

make check valt om op een bedorven build/test_cache, en de melding wijst naar de verkeerde test #798

New issue
Closed
opened 2026-07-24 13:54:31 +00:00 by brenno · 4 comments
brenno commented 2026-07-24 13:54:31 +00:00
Owner
Copy link

make check viel op 24-07-2026 twee keer om op een fout die niets met de genoemde test te maken heeft:

Failed to load "…/test/<willekeurig>_test.dart":
type '_Map<String, dynamic>' is not a subtype of type 'List<dynamic>' in type cast

Het is een fout bij het laden van een testbestand, niet bij het uitvoeren ervan. Het genoemde bestand verschilt per keer en is los altijd groen.

Waargenomen

# Testbestand Fase Suitepositie
1 test/render_page_serialisation_test.dart == OciDeck check: coverage == +460
2 test/privacy_dismissal_panel_test.dart == OciDeck check: coverage == +4827

Allebei los gedraaid: groen. Allebei weg na rm -rf build/test_cache, waarna dezelfde make check zonder wijziging groen liep.

Wat het correleert

Zes volledige suiteruns op één dag, waarvan twee omgevallen. Beide voorvallen zaten in de --coverage-fase. De vier runs die geen dekking meten bleven schoon:

  • make test — schoon
  • make check-no-coverage — schoon
  • make check direct ná het legen van de cache — twee keer schoon (dus de dekkingsfase op zichzelf is niet genoeg)

De gemene deler is dus niet "coverage" alleen en niet "een volle cache" alleen, maar de combinatie: de dekkingsfase op een cache die uit eerdere runs is meegedragen. Dat is een waarneming uit zes runs, geen bewezen oorzaak — de steekproef is te klein om --coverage als noodzakelijke voorwaarde te verklaren.

Wat die cache is

build/test_cache/build/<hash>.cache.dill.track.dill — de incrementele kernelcache die flutter test zelf aanlegt. Niet iets wat deze repo instelt: er staat niets over in Makefile, dart_test.yaml of pubspec.yaml. Flutter 3.44.7-stable (de pin). Bij de laatste meting 119 MB.

De foutmelding past bij het deserialiseren van bedorven of verouderde cachegegevens: een map waar een lijst werd verwacht.

Waarom dit meer is dan ruis

Niet omdat het vaak gebeurt, maar omdat de melding naar de verkeerde plek wijst. Wie dit voor het eerst ziet, gaat de genoemde test debuggen — die groen is. Dat is precies het patroon van #714 en #782: een kale uitzondering die de oorzaak niet noemt, waar hier bovenop komt dat het bestand dat hij wél noemt onschuldig is.

Er staat nu niets over in docs/CHECKS.md; het zit alleen in de hoofden van wie het eerder heeft meegemaakt.

Richtingen (open, niet voorgeschreven)

  • Het goedkoopste: een regel in docs/CHECKS.md bij de probleemoplossing — deze foutsignatuur betekent de cache, niet de test.
  • Iets steviger: make check de signatuur laten herkennen en het advies afdrukken in plaats van de gebruiker het te laten uitzoeken. Wel oppassen dat dat geen echte laadfouten wegpoetst.
  • Een make clean-test-cache-doel zodat het recept ergens vastligt in plaats van in een reactie.
  • Uitzoeken of dit bovenstrooms bekend is bij Flutter. Ik heb dat niet nagekeken en doe daar dus geen bewering over.

Blind build/test_cache weggooien vóór elke run lost het op en kost de incrementele compilatie — dat lijkt me de verkeerde ruil, maar het is een optie.

Weging

Lage prioriteit: het blokkeert niets blijvend en het herstel is één opdracht. Wat het kost is de tijd van degene die het niet herkent, en dat is precies wat een regel documentatie wegneemt.

`make check` viel op 24-07-2026 twee keer om op een fout die niets met de genoemde test te maken heeft: ``` Failed to load "…/test/<willekeurig>_test.dart": type '_Map<String, dynamic>' is not a subtype of type 'List<dynamic>' in type cast ``` Het is een fout bij het **laden** van een testbestand, niet bij het uitvoeren ervan. Het genoemde bestand verschilt per keer en is los altijd groen. ## Waargenomen | # | Testbestand | Fase | Suitepositie | | --- | --- | --- | --- | | 1 | `test/render_page_serialisation_test.dart` | `== OciDeck check: coverage ==` | +460 | | 2 | `test/privacy_dismissal_panel_test.dart` | `== OciDeck check: coverage ==` | +4827 | Allebei los gedraaid: groen. Allebei weg na `rm -rf build/test_cache`, waarna dezelfde `make check` zonder wijziging groen liep. ## Wat het correleert Zes volledige suiteruns op één dag, waarvan twee omgevallen. **Beide voorvallen zaten in de `--coverage`-fase.** De vier runs die geen dekking meten bleven schoon: - `make test` — schoon - `make check-no-coverage` — schoon - `make check` direct ná het legen van de cache — twee keer schoon (dus de dekkingsfase op zichzelf is niet genoeg) De gemene deler is dus niet "coverage" alleen en niet "een volle cache" alleen, maar de combinatie: de dekkingsfase op een cache die uit eerdere runs is meegedragen. Dat is een waarneming uit zes runs, geen bewezen oorzaak — de steekproef is te klein om `--coverage` als noodzakelijke voorwaarde te verklaren. ## Wat die cache is `build/test_cache/build/<hash>.cache.dill.track.dill` — de incrementele kernelcache die `flutter test` zelf aanlegt. Niet iets wat deze repo instelt: er staat niets over in `Makefile`, `dart_test.yaml` of `pubspec.yaml`. Flutter 3.44.7-stable (de pin). Bij de laatste meting 119 MB. De foutmelding past bij het deserialiseren van bedorven of verouderde cachegegevens: een map waar een lijst werd verwacht. ## Waarom dit meer is dan ruis Niet omdat het vaak gebeurt, maar omdat de melding **naar de verkeerde plek wijst**. Wie dit voor het eerst ziet, gaat de genoemde test debuggen — die groen is. Dat is precies het patroon van #714 en #782: een kale uitzondering die de oorzaak niet noemt, waar hier bovenop komt dat het bestand dat hij wél noemt onschuldig is. Er staat nu niets over in `docs/CHECKS.md`; het zit alleen in de hoofden van wie het eerder heeft meegemaakt. ## Richtingen (open, niet voorgeschreven) - Het goedkoopste: een regel in `docs/CHECKS.md` bij de probleemoplossing — deze foutsignatuur betekent de cache, niet de test. - Iets steviger: `make check` de signatuur laten herkennen en het advies afdrukken in plaats van de gebruiker het te laten uitzoeken. Wel oppassen dat dat geen echte laadfouten wegpoetst. - Een `make clean-test-cache`-doel zodat het recept ergens vastligt in plaats van in een reactie. - Uitzoeken of dit bovenstrooms bekend is bij Flutter. Ik heb dat niet nagekeken en doe daar dus geen bewering over. Blind `build/test_cache` weggooien vóór elke run lost het op en kost de incrementele compilatie — dat lijkt me de verkeerde ruil, maar het is een optie. ## Weging Lage prioriteit: het blokkeert niets blijvend en het herstel is één opdracht. Wat het kost is de tijd van degene die het niet herkent, en dat is precies wat een regel documentatie wegneemt.
brenno commented 2026-07-24 17:56:19 +00:00
Author
Owner
Copy link

Opgepakt. Tak: fix/testcache-laadfout-798.

Ik neem je vier richtingen alle vier mee, en begin met de vierde omdat die de andere drie stuurt: waar komt die cast vandaan. Eerste bevinding uit de SDK zelf — getDefaultCachedKernelPath (packages/flutter_tools/lib/src/bundle.dart) hasht alléén de dart-defines en de extra frontend-opties in de bestandsnaam. Niet de SDK-versie, niet pubspec.lock. Dezelfde <hash>.cache.dill.track.dill wordt dus hergebruikt over een Flutter-upgrade of een dependencywijziging heen. Dat is een mechanisme dat bij je waarneming past; of het jóuw twee voorvallen verklaart weet ik nog niet, en ik ga daar geen bewering over doen die ik niet kan tonen.

Wat ik denk te raken: Makefile (een opruimdoel plus signatuurherkenning die geen echte laadfout wegpoetst), docs/CHECKS.md (probleemoplossing — die sectie bestaat daar nu niet), en een poort in tool/ met een test, want de herkenning zelf moet aantoonbaar geen valse stilte veroorzaken.

Opgepakt. Tak: `fix/testcache-laadfout-798`. Ik neem je vier richtingen alle vier mee, en begin met de vierde omdat die de andere drie stuurt: waar komt die cast vandaan. Eerste bevinding uit de SDK zelf — `getDefaultCachedKernelPath` (`packages/flutter_tools/lib/src/bundle.dart`) hasht alléén de dart-defines en de extra frontend-opties in de bestandsnaam. Niet de SDK-versie, niet `pubspec.lock`. Dezelfde `<hash>.cache.dill.track.dill` wordt dus hergebruikt over een Flutter-upgrade of een dependencywijziging heen. Dat is een mechanisme dat bij je waarneming past; of het jóuw twee voorvallen verklaart weet ik nog niet, en ik ga daar geen bewering over doen die ik niet kan tonen. Wat ik denk te raken: `Makefile` (een opruimdoel plus signatuurherkenning die geen echte laadfout wegpoetst), `docs/CHECKS.md` (probleemoplossing — die sectie bestaat daar nu niet), en een poort in `tool/` met een test, want de herkenning zelf moet aantoonbaar geen valse stilte veroorzaken.
brenno commented 2026-07-24 18:31:49 +00:00
Author
Owner
Copy link

Gemerged: 31a5e430 (PR #815), op main geverifieerd. Alle vier je richtingen zitten erin — en de vierde heeft de andere drie omgegooid: de cache is de verkeerde verdachte.

De storing viel tijdens dit werk zélf, mét stack

In de dekkingsfase, op test/import/snappy_test.dart, test 5507 van 6528 — jouw signatuur letterlijk. De stack is beslissend:

dart:_internal/async_cast.dart 80:25   CastStreamSubscription._onData

Dat is Stream.cast<T>(), niet een gewone waarde-cast. De enige plek in deze keten die zo cast is stream_channel/lib/src/multi_channel.dart:143: _inner!.stream.cast<List>(). MultiChannel multiplext meerdere logische kanalen over één verbinding, dus elk frame hoort een [id, inhoud]-lijst te zijn. Een kale List in een cast is voor de VM List<dynamic> — vandaar exact die tekst, en vandaar een stack met niets dan dart:async erboven. Er kwam dus een JSON-object langs op een lijn die alleen frames vervoert. In flutter test is dat de lijn tussen het gereedschap en het testproces (_pipeHarnessToRemote in flutter_platform.dart), JSON over een WebSocket.

Het is dus niet die test, en niet de cache.

Wat weerlegd is

Drie manieren om die cache te bederven, tegen een echte draai van deze suite: halveren, ~2.800 bytes omklappen, en vervangen door een geldige dill uit een andere bronboom. Alle drie groen — de frontend server valt terug op een volledige compilatie. Je eigen formulering ("bedorven of verouderde cachegegevens") houdt daarmee geen stand. De tabel staat in docs/CHECKS.md zodat niemand die proeven overdoet.

Wat de drie bekende voorvallen wél gemeen hebben is belasting: alle drie in de dekkingsfase, en mijn reproductie viel terwijl er een tweede flutter test op dezelfde machine liep. Drie is geen steekproef, dus dat staat er als waarneming en niet als oorzaak. De gooiende regel staat vast, de aanleiding niet.

Dat het opruimen van de cache "hielp" is hiermee consistent — een volledige hercompilatie verzet de timing van de hele draai — maar opnieuw draaien is dat evenzeer.

Richting 2, met jouw voorbehoud

Je waarschuwde dat het geen echte laadfouten mag wegpoetsen. Dat is opgelost door het niet over de uitvoer te doen: elke flutter test schrijft náást het scherm een machineleesbaar rapport (--file-reporter json:build/test-report.json), en tool/explain_suite_failure.dart leest dát bij een rode suite. Een zijkanaal kan per definitie niets onderdrukken — de uitvoer stroomt onveranderd door en de afloop blijft die van de suite. Filteren was ook praktisch onmogelijk: een pipe kost flutter test zijn voortgangsregel en maakt van een draai duizenden regels.

De verklaring noemt de bestanden die niet geladen konden worden, mét de zin die er anders bij inschiet: dat de tests erin niet gedraaid hebben en niet meetellen in het aantal.

Belangrijker dan de geruststelling is het omgekeerde. Een bestand dat niet compileert is óók een laadfout, en die wordt juist als échte fout benoemd — nooit weggezet als "bekend". Dat is de eerste toets in test/explain_suite_failure_test.dart, met een ontbrekende main, een mislukte compilatie en een ongerelateerde type-cast. Stond die verkeerd, dan was dit hulpmiddel erger dan geen hulpmiddel.

Richtingen 1 en 3

docs/CHECKS.md heeft nu een sectie When the gate fails on something that is not your change, met de letterlijke signatuur erin zodat wie hem intikt daar landt. En make clean-test-cache bestaat — alleen build/test_cache, bewust niet flutter clean: daaronder staan de platformbuilds waar DARTCV_LIB de native OpenCV-bibliotheek vindt, en die weggooien laat de gezichtsdetectietests zichzelf weer overslaan. Groen om de verkeerde reden.

Je noemde blind opruimen vóór elke draai de verkeerde ruil. Eens, en het is nu ook niet meer het eerste advies: dat is opnieuw draaien.

Richting 4, bovenstrooms

Twee reports, geen van beide dit:

  • flutter/flutter#49351 — dezelfde foutvórm, ook toegeschreven aan een meegedragen .dill.track.dill. In 2020 gesloten: het bleek een pakketversieverschil tussen twee omgevingen. De cache was daar óók de rode haring.
  • flutter/flutter#128563 — open. De zustercache van flutter test onder build/ wordt niet ongeldig wanneer Flutter het formaat wijzigt, en de conclusie van de melder is letterlijk dat opruimen de enige remedie is en dat dat niet vanzelf duidelijk is. Andere cache, jouw klacht.

Wat er níét in zit

Een preventieve vervaldatum op de cache. Overwogen, want de bestandsnaam hasht alleen de dart-defines en de frontend-opties (getDefaultCachedKernelPath) en overleeft dus een SDK- of pakketwijziging. Geschrapt zodra bleek dat de cache de oorzaak niet is: dan koop je een hercompilatie voor een theorie.

Waarom dit issue open blijft

De aanleiding is niet gevonden. Wat er nog ligt is één ding, en dat is jouw keuze: een melding bovenstrooms bij dart-lang/test of flutter. De sluitende stap daarvoor is een reproductie die niet "een suite van 6.500 tests onder belasting" heet, en die heb ik niet. Ik heb wel het volledige rapport, de volledige uitvoer en de cache van de reproductie bewaard; zeg het maar als je die erbij wilt.

Poort: make check groen op de tak in een verse worktree — 6.539 tests, dekking 86,5%, per-bestandsvloer 0. Elk van de zes toetsen is één keer rood gezien tegen een gemuteerde tool, Makefile en docs.

Gemerged: `31a5e430` (PR #815), op main geverifieerd. Alle vier je richtingen zitten erin — en de vierde heeft de andere drie omgegooid: **de cache is de verkeerde verdachte.** ## De storing viel tijdens dit werk zélf, mét stack In de dekkingsfase, op `test/import/snappy_test.dart`, test 5507 van 6528 — jouw signatuur letterlijk. De stack is beslissend: ``` dart:_internal/async_cast.dart 80:25 CastStreamSubscription._onData ``` Dat is `Stream.cast<T>()`, niet een gewone waarde-cast. De enige plek in deze keten die zo cast is `stream_channel/lib/src/multi_channel.dart:143`: `_inner!.stream.cast<List>()`. `MultiChannel` multiplext meerdere logische kanalen over één verbinding, dus elk frame hoort een `[id, inhoud]`-**lijst** te zijn. Een kale `List` in een cast is voor de VM `List<dynamic>` — vandaar exact die tekst, en vandaar een stack met niets dan `dart:async` erboven. Er kwam dus een JSON-**object** langs op een lijn die alleen frames vervoert. In `flutter test` is dat de lijn tussen het gereedschap en het testproces (`_pipeHarnessToRemote` in `flutter_platform.dart`), JSON over een WebSocket. Het is dus niet die test, en niet de cache. ## Wat weerlegd is Drie manieren om die cache te bederven, tegen een echte draai van deze suite: halveren, ~2.800 bytes omklappen, en vervangen door een geldige dill uit een andere bronboom. **Alle drie groen** — de frontend server valt terug op een volledige compilatie. Je eigen formulering ("bedorven of verouderde cachegegevens") houdt daarmee geen stand. De tabel staat in `docs/CHECKS.md` zodat niemand die proeven overdoet. Wat de drie bekende voorvallen wél gemeen hebben is **belasting**: alle drie in de dekkingsfase, en mijn reproductie viel terwijl er een tweede `flutter test` op dezelfde machine liep. Drie is geen steekproef, dus dat staat er als waarneming en niet als oorzaak. De gooiende regel staat vast, de aanleiding niet. Dat het opruimen van de cache "hielp" is hiermee consistent — een volledige hercompilatie verzet de timing van de hele draai — maar opnieuw draaien is dat evenzeer. ## Richting 2, met jouw voorbehoud Je waarschuwde dat het geen echte laadfouten mag wegpoetsen. Dat is opgelost door het niet over de uitvoer te doen: elke `flutter test` schrijft náást het scherm een machineleesbaar rapport (`--file-reporter json:build/test-report.json`), en `tool/explain_suite_failure.dart` leest dát bij een rode suite. Een zijkanaal kan per definitie niets onderdrukken — de uitvoer stroomt onveranderd door en de afloop blijft die van de suite. Filteren was ook praktisch onmogelijk: een pipe kost `flutter test` zijn voortgangsregel en maakt van een draai duizenden regels. De verklaring noemt de bestanden die niet **geladen** konden worden, mét de zin die er anders bij inschiet: dat de tests erin niet gedraaid hebben en niet meetellen in het aantal. **Belangrijker dan de geruststelling is het omgekeerde.** Een bestand dat niet compileert is óók een laadfout, en die wordt juist als échte fout benoemd — nooit weggezet als "bekend". Dat is de eerste toets in `test/explain_suite_failure_test.dart`, met een ontbrekende `main`, een mislukte compilatie en een ongerelateerde type-cast. Stond die verkeerd, dan was dit hulpmiddel erger dan geen hulpmiddel. ## Richtingen 1 en 3 `docs/CHECKS.md` heeft nu een sectie *When the gate fails on something that is not your change*, met de letterlijke signatuur erin zodat wie hem intikt daar landt. En `make clean-test-cache` bestaat — alleen `build/test_cache`, bewust niet `flutter clean`: daaronder staan de platformbuilds waar `DARTCV_LIB` de native OpenCV-bibliotheek vindt, en die weggooien laat de gezichtsdetectietests zichzelf weer overslaan. Groen om de verkeerde reden. Je noemde blind opruimen vóór elke draai de verkeerde ruil. Eens, en het is nu ook niet meer het eerste advies: dat is opnieuw draaien. ## Richting 4, bovenstrooms Twee reports, geen van beide dit: - flutter/flutter#49351 — dezelfde foutvórm, ook toegeschreven aan een meegedragen `.dill.track.dill`. In 2020 gesloten: het bleek een **pakketversieverschil** tussen twee omgevingen. De cache was daar óók de rode haring. - flutter/flutter#128563 — **open**. De zustercache van `flutter test` onder `build/` wordt niet ongeldig wanneer Flutter het formaat wijzigt, en de conclusie van de melder is letterlijk dat opruimen de enige remedie is en dat dat niet vanzelf duidelijk is. Andere cache, jouw klacht. ## Wat er níét in zit Een preventieve vervaldatum op de cache. Overwogen, want de bestandsnaam hasht alleen de dart-defines en de frontend-opties (`getDefaultCachedKernelPath`) en overleeft dus een SDK- of pakketwijziging. Geschrapt zodra bleek dat de cache de oorzaak niet is: dan koop je een hercompilatie voor een theorie. ## Waarom dit issue open blijft De aanleiding is niet gevonden. Wat er nog ligt is één ding, en dat is jouw keuze: **een melding bovenstrooms bij `dart-lang/test` of `flutter`.** De sluitende stap daarvoor is een reproductie die niet "een suite van 6.500 tests onder belasting" heet, en die heb ik niet. Ik heb wel het volledige rapport, de volledige uitvoer en de cache van de reproductie bewaard; zeg het maar als je die erbij wilt. Poort: `make check` groen op de tak in een verse worktree — 6.539 tests, dekking 86,5%, per-bestandsvloer 0. Elk van de zes toetsen is één keer rood gezien tegen een gemuteerde tool, Makefile en docs.
brenno commented 2026-07-24 20:22:55 +00:00
Author
Owner
Copy link

Vierde voorval, vandaag 24-07 tijdens het werk aan #811. Genoteerd omdat elke waarneming hier telt — het zijn er nu vier.
Testbestand test/markdown_editor_lossless_test.dart
Fase == OciDeck check: coverage ==
Suitepositie +6557 (van ~6561)
Signatuur type '_Map<String, dynamic>' is not a subtype of type 'List<dynamic>' in type cast

Weer een ander bestand, weer de dekkingsfase. Opnieuw draaien was genoeg; de cache is niet aangeraakt.

Wat dit met de belastingwaarneming doet: het verzwakt hem. Er liep deze keer geen tweede flutter test van mij. Wat ik níét kan uitsluiten is een andere sessie op dezelfde machine — daar heb ik geen zicht op, dus dit is geen weerlegging, alleen een voorval dat de theorie niet steunt. Nieuw is verder dat het in een worktree op /private/tmp viel en niet in de hoofdwerkkopie.

Het gereedschap uit #815 deed precies waarvoor het gemaakt is. De suite noemde markdown_editor_lossless_test.dart als 'failing test', en de verklaring eronder zette dat recht: dit bestand kon niet worden geladen, de tests erin hebben niet gedraaid en tellen niet mee, en dit is de bekende storing en niet die test. Ik heb geen seconde aan dat bestand besteed. Dat was de hele bedoeling.

De aanleiding is nog steeds niet gevonden, dus dit issue blijft open — en de bovenstroomse melding blijft jouw keuze.

Vierde voorval, vandaag 24-07 tijdens het werk aan #811. Genoteerd omdat elke waarneming hier telt — het zijn er nu vier. | | | |---|---| | Testbestand | `test/markdown_editor_lossless_test.dart` | | Fase | `== OciDeck check: coverage ==` | | Suitepositie | +6557 (van ~6561) | | Signatuur | `type '_Map<String, dynamic>' is not a subtype of type 'List<dynamic>' in type cast` | Weer een ander bestand, weer de dekkingsfase. Opnieuw draaien was genoeg; de cache is niet aangeraakt. **Wat dit met de belastingwaarneming doet: het verzwakt hem.** Er liep deze keer geen tweede `flutter test` van mij. Wat ik níét kan uitsluiten is een andere sessie op dezelfde machine — daar heb ik geen zicht op, dus dit is geen weerlegging, alleen een voorval dat de theorie niet steunt. Nieuw is verder dat het in een **worktree** op `/private/tmp` viel en niet in de hoofdwerkkopie. **Het gereedschap uit #815 deed precies waarvoor het gemaakt is.** De suite noemde `markdown_editor_lossless_test.dart` als 'failing test', en de verklaring eronder zette dat recht: dit bestand kon niet worden *geladen*, de tests erin hebben niet gedraaid en tellen niet mee, en dit is de bekende storing en niet die test. Ik heb geen seconde aan dat bestand besteed. Dat was de hele bedoeling. De aanleiding is nog steeds niet gevonden, dus dit issue blijft open — en de bovenstroomse melding blijft jouw keuze.
brenno commented 2026-07-24 20:23:29 +00:00
Author
Owner
Copy link

Afgerond en gesloten. De tegenmaatregel staat op main (31a5e430, PR #815); wat overbleef was de aanleiding, en die schrijven we af als pech.

Bovenstrooms gemeld: flutter/flutter#190000, met een reproductie in een leeg, gegenereerd project — 400 testbestanden, --coverage, en lussen. Dat issue blijft daar open voor hun triage; het kost ons niets en er zit een tweede bevinding in die losstaat van de flakiness (zie hieronder).

Wat er in dit issue is beantwoord:

  • Richting 1 — docs/CHECKS.md heeft een sectie met de letterlijke foutsignatuur, zodat wie hem intikt daar landt en niet bij de test die genoemd wordt.
  • Richting 2 — élke flutter test schrijft nu een machineleesbaar rapport náást het scherm, en tool/explain_suite_failure.dart leest dat bij een rode suite. Jouw voorbehoud (geen echte laadfouten wegpoetsen) is opgelost door het via een zijkanaal te doen: er wordt niets afgevangen of onderdrukt. Een bestand dat niet compileert wordt juist als échte fout benoemd.
  • Richting 3 — make clean-test-cache bestaat, maar is niet meer het eerste advies. Dat is opnieuw draaien.
  • Richting 4 — gemeld, zie boven.

De titel van dit issue klopt niet meer, en dat is de moeite waard om te onthouden. "valt om op een bedorven build/test_cache" — de cache is het niet. Drie manieren om hem te bederven leverden alle drie een groene suite op; de gooiende regel is stream_channel/lib/src/multi_channel.dart:143, op de lijn tussen flutter test en het testproces. Dat de cache opruimen tweemaal "hielp" was een volledige hercompilatie die de timing verzette, niet een oorzaak die verdween.

Eén bevinding die los van dit alles staat en de moeite waard blijft. In de reproductie meldde de draai 1596 van de 1600 tests. De vier tests uit het niet-geladen bestand hebben niet gedraaid en staan nergens geteld — de suite toetst dus minder dan het getal zegt, en niets meldt dat. Bij ons vangt de nieuwe verklaring dat nu af met een expliciete zin; bovenstrooms staat het als zelfstandig punt in het issue.

Wat er níét is gevonden: de aanleiding. Wat de bekende voorvallen delen is belasting, maar drie waarnemingen zijn geen steekproef en 39 synthetische draaien leverden één treffer. Ik heb twee hypotheses uitgesloten (meer bestanden, hogere concurrency) en één ongetoetst achtergelaten in het upstream-issue: dat het gaat om de overlap tussen processen die nog dráaien en processen die geladen worden — de échte suite valt ~1 op 3, de synthetische ~1 op 39, en dát is het verschil tussen die twee.

Komt hij terug, dan staat in docs/CHECKS.md wat je moet bewaren voordat je iets opruimt.

Afgerond en gesloten. De tegenmaatregel staat op main (`31a5e430`, PR #815); wat overbleef was de aanleiding, en die schrijven we af als pech. **Bovenstrooms gemeld:** [flutter/flutter#190000](https://github.com/flutter/flutter/issues/190000), met een reproductie in een leeg, gegenereerd project — 400 testbestanden, `--coverage`, en lussen. Dat issue blijft daar open voor hun triage; het kost ons niets en er zit een tweede bevinding in die losstaat van de flakiness (zie hieronder). **Wat er in dit issue is beantwoord:** - **Richting 1** — `docs/CHECKS.md` heeft een sectie met de letterlijke foutsignatuur, zodat wie hem intikt daar landt en niet bij de test die genoemd wordt. - **Richting 2** — élke `flutter test` schrijft nu een machineleesbaar rapport náást het scherm, en `tool/explain_suite_failure.dart` leest dat bij een rode suite. Jouw voorbehoud (geen echte laadfouten wegpoetsen) is opgelost door het via een zijkanaal te doen: er wordt niets afgevangen of onderdrukt. Een bestand dat niet compileert wordt juist als échte fout benoemd. - **Richting 3** — `make clean-test-cache` bestaat, maar is niet meer het eerste advies. Dat is opnieuw draaien. - **Richting 4** — gemeld, zie boven. **De titel van dit issue klopt niet meer, en dat is de moeite waard om te onthouden.** "valt om op een bedorven build/test_cache" — de cache is het niet. Drie manieren om hem te bederven leverden alle drie een groene suite op; de gooiende regel is `stream_channel/lib/src/multi_channel.dart:143`, op de lijn tussen `flutter test` en het testproces. Dat de cache opruimen tweemaal "hielp" was een volledige hercompilatie die de timing verzette, niet een oorzaak die verdween. **Eén bevinding die los van dit alles staat en de moeite waard blijft.** In de reproductie meldde de draai **1596 van de 1600 tests**. De vier tests uit het niet-geladen bestand hebben niet gedraaid en staan nergens geteld — de suite toetst dus minder dan het getal zegt, en niets meldt dat. Bij ons vangt de nieuwe verklaring dat nu af met een expliciete zin; bovenstrooms staat het als zelfstandig punt in het issue. **Wat er níét is gevonden:** de aanleiding. Wat de bekende voorvallen delen is belasting, maar drie waarnemingen zijn geen steekproef en 39 synthetische draaien leverden één treffer. Ik heb twee hypotheses uitgesloten (meer bestanden, hogere concurrency) en één ongetoetst achtergelaten in het upstream-issue: dat het gaat om de overlap tussen processen die nog dráaien en processen die geladen worden — de échte suite valt ~1 op 3, de synthetische ~1 op 39, en dát is het verschil tussen die twee. Komt hij terug, dan staat in `docs/CHECKS.md` wat je moet bewaren voordat je iets opruimt.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/markdown-editor-translations
codex/markdown-editor-ux
codex/template-followup
cockpit-wip
v0.1.3
v0.1.2
v0.1.1
v0.1.0
archive/git-mirror
Labels
Clear labels   
accepted
Assessed and will be built

  
bug
Something is broken

  
declined
Assessed and will not be built

  
docs
Documentation only

  
duplicate
Already tracked elsewhere

  
enhancement
New feature or improvement request

  
good first issue
Small, self-contained, and a good place to start

  
in-progress
Someone is working on this right now. Do not start it in parallel.

  
needs-info
Waiting for the reporter

  
privacy
Personal data can leak. Handled before anything else.

  
security
A weakness someone could use. Handled before anything else.

  
triage
Awaiting assessment

No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck#798
No description provided.