fix(crop): een mislukte rotatie is niet langer spoorloos #1774

Merged

brenno merged 1 commit from fix/rotatie-windows-diagnose into main

2026-08-24 12:58:58 +00:00

brenno commented

2026-08-24 12:48:17 +00:00

Owner

Waarom

De spiegel-CI op main staat na #1762/#1763 nog op twee rode tests, allebei in image_crop_dialog_test.dart (van de zeventien: Gate (Linux) groen, Docs links groen, vijftien Windows-toetsen groen, deze twee niet). Het bestand op schijf blijft onveranderd, dus de rotatie landt niet.

Mijn vorige poging schoot mis. De ontbrekende Windows-terugval in writeBytesAtomicSync was een echte fout — de bibliotheekdoc beloofde hem — maar hij was niet de oorzaak hiervan.

Het eigenlijke gebrek is dat ik het niet kán zien. _writeRotatedBytes heeft vier uitgangen die niets wegschrijven: bytes nooit geladen, niet te decoderen, pad buiten de projectmap, of de schrijfbeurt gooit. Alle vier waren stil. De schrijffout werd bewust ingeslikt, en met reden — een volle schijf of een alleen-lezen map mag de bijsnijdkeuze niet blokkeren. Maar logWarning schrijft naar de VM-servicestroom, niet naar de testuitvoer, dus in CI zie je alleen Expected: [0,0,255] Actual: [255,0,0]. De enige route naar de oorzaak was gokken en een uur op de spiegel wachten. Dat heb ik één keer gedaan; niet nog eens.

Wat er verandert

Elke uitgang zet lastRotationWriteFailure (de fout, of een korte reden). Alleen de fout of die reden — nooit een pad of bestandsinhoud.
De schrijffout gaat óók naar logWarning. In de app was dit namelijk hetzelfde gat: een gebruiker op Windows draait een afbeelding, ziet de preview draaien, en er gebeurt niets. Geen melding, geen spoor.
De twee rotatietoetsen kijken naar die reden vóór ze naar de pixels kijken.

Wat dit níet is

Dit repareert de rotatie niet. Het maakt de volgende spiegel-run bruikbaar. Ik heb bewust geen tweede gok ingebouwd (mijn beste hypothese was een openstaande bestandshandle van de beeldcache — plausibel gezien de errno-32-fouten in twee andere Windows-toetsen, maar niet meer dan dat). Zodra Windows de reden noemt, komt de reparatie mét een toets die op de juiste plek rood staat.

Toetsing

make check groen (exit 0).
De diagnose zelf geverifieerd door writeBytesAtomicSync lokaal te laten gooien: de toets meldt dan FileSystemException: nagebootste Windows-fout in plaats van "verwacht blauw, kreeg rood".

Bewaker

Overgeslagen, expliciet: geen formaat, opslag, afhankelijkheid of publieke belofte. Wel raakt het waarneembaarheid van een stille fout, en dat gaat de goede kant op.

## Waarom De spiegel-CI op main staat na #1762/#1763 nog op twee rode tests, allebei in `image_crop_dialog_test.dart` (van de zeventien: `Gate (Linux)` groen, `Docs links` groen, vijftien Windows-toetsen groen, deze twee niet). Het bestand op schijf blijft onveranderd, dus de rotatie landt niet. Mijn vorige poging schoot mis. De ontbrekende Windows-terugval in `writeBytesAtomicSync` was een echte fout — de bibliotheekdoc beloofde hem — maar hij was niet de oorzaak hiervan. **Het eigenlijke gebrek is dat ik het niet kán zien.** `_writeRotatedBytes` heeft vier uitgangen die niets wegschrijven: bytes nooit geladen, niet te decoderen, pad buiten de projectmap, of de schrijfbeurt gooit. Alle vier waren stil. De schrijffout werd bewust ingeslikt, en met reden — een volle schijf of een alleen-lezen map mag de bijsnijdkeuze niet blokkeren. Maar `logWarning` schrijft naar de VM-servicestroom, niet naar de testuitvoer, dus in CI zie je alleen `Expected: [0,0,255] Actual: [255,0,0]`. De enige route naar de oorzaak was gokken en een uur op de spiegel wachten. Dat heb ik één keer gedaan; niet nog eens. ## Wat er verandert - Elke uitgang zet `lastRotationWriteFailure` (de fout, of een korte reden). Alleen de fout of die reden — nooit een pad of bestandsinhoud. - De schrijffout gaat óók naar `logWarning`. In de app was dit namelijk hetzelfde gat: een gebruiker op Windows draait een afbeelding, ziet de preview draaien, en er gebeurt niets. Geen melding, geen spoor. - De twee rotatietoetsen kijken naar die reden vóór ze naar de pixels kijken. ## Wat dit níet is **Dit repareert de rotatie niet.** Het maakt de volgende spiegel-run bruikbaar. Ik heb bewust geen tweede gok ingebouwd (mijn beste hypothese was een openstaande bestandshandle van de beeldcache — plausibel gezien de errno-32-fouten in twee andere Windows-toetsen, maar niet meer dan dat). Zodra Windows de reden noemt, komt de reparatie mét een toets die op de juiste plek rood staat. ## Toetsing - `make check` groen (exit 0). - De diagnose zelf geverifieerd door `writeBytesAtomicSync` lokaal te laten gooien: de toets meldt dan `FileSystemException: nagebootste Windows-fout` in plaats van "verwacht blauw, kreeg rood". ## Bewaker Overgeslagen, expliciet: geen formaat, opslag, afhankelijkheid of publieke belofte. Wel raakt het waarneembaarheid van een stille fout, en dat gaat de goede kant op.

brenno added 1 commit

2026-08-24 12:48:19 +00:00

fix(crop): een mislukte rotatie is niet langer spoorloos

scans / scans (pull_request) Successful in 5m40s

Details

static-gate / static-gate (pull_request) Successful in 9m35s

Details

ff1f1bae40

De twee rotatietoetsen staan op de Windows-spiegel al drie releases rood, en na
mijn vorige poging nog steeds: de terugval in `writeBytesAtomicSync` was nodig,
maar niet de oorzaak. Ik kon niet zien wát er misgaat, en dat is het eigenlijke
gebrek — niet de rotatie.

`_writeRotatedBytes` heeft vier uitgangen die niets wegschrijven (bytes nooit
geladen, niet te decoderen, pad buiten de projectmap, schrijffout) en alle vier
waren stil. De schrijffout werd zelfs bewust ingeslikt, met reden: een volle
schijf mag de bijsnijdkeuze niet blokkeren. Alleen: `logWarning` schrijft naar
de VM-servicestroom, niet naar de testuitvoer, dus in CI zag je alleen pixels
die niet klopten. Twee releases lang was de enige route naar de oorzaak: gokken
en een uur op de spiegel wachten.

Elke uitgang zet nu `lastRotationWriteFailure`, en de schrijffout gaat óók naar
`logWarning` — in de app was "draaien doet niets, zonder melding" precies wat de
gebruiker op Windows kreeg. De twee toetsen kijken naar die reden vóór ze naar
de pixels kijken.

Geverifieerd door de schrijfbeurt lokaal te laten mislukken: de toets meldt dan
de FileSystemException in plaats van "verwacht blauw, kreeg rood".

Dit repareert de rotatie niet. Het maakt de volgende spiegel-run bruikbaar.

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

brenno merged commit 183db94b0f into main

2026-08-24 12:58:58 +00:00

brenno referenced this pull request from a commit

2026-08-24 12:59:00 +00:00

fix(crop): een mislukte rotatie is niet langer spoorloos (#1774)

brenno referenced this pull request

2026-08-24 14:22:44 +00:00

fix(crop): rotatie op Windows landt weer, en een mislukte schrijfbeurt wist niets meer #1776

brenno referenced this pull request from a commit

2026-08-24 14:22:45 +00:00

fix(crop): rotatie op Windows landt weer, en een mislukte schrijfbeurt wist niets meer

brenno referenced this pull request