Mislukt crashherstel meldt niets: de gebruiker denkt beschermd te zijn #1953

New issue

Closed

opened 2026-09-03 10:14:38 +00:00 by brenno · 0 comments

brenno commented

2026-09-03 10:14:38 +00:00

Owner

Het probleem

Onopgeslagen werk wordt elke 25 seconden als herstelkopie weggeschreven. Faalt dat schrijven (schijf vol, rechten, pad weg), dan gaat het naar het logboek en verder niets. Geen snackbar, geen status, geen "herstel werkt nu niet".

Op desktop is crashherstel de belofte: de handleiding zegt dat onopgeslagen werk terugkomt. Wie die belofte vertrouwt en daarna crasht, is het werk kwijt zonder ooit te hebben gehoord dat de vangnetten kapot waren.

De browserversie zegt dit wél één keer ("hier is geen herstel"). De desktopversie zwijgt als herstel onverwacht uitvalt.

Daarnaast: bij een harde kill (kill -9, stroom uit) tussen twee ticks ontbreekt de laatste ~25 s sowieso — dat is de inherente kloof van interval-autosave. Dit issue gaat over het stille falen van de write, niet over die kloof zelf.

Hoe het nu werkt

lib/services/recovery_service.dart, save:

} catch (e) {
  logWarning('RecoveryService.save: write recovery snapshot', e);
  // Autosave mag nooit de app verstoren.
}

Bewuste keuze: autosave mag de editor niet laten haperen. Het gevolg is dat de enige waarnemer van falen een logregel is die de gebruiker niet ziet.

recovery_service_test.dart dekt de happy path en de save/discard-race, niet een schrijffout naar schijf.

Denkrichting (niet uitgewerkt)

Eén stille fout mag in het log. De eerste fout in een sessie (of de eerste na een geslaagde write) hoort in de UI: kort, niet blokkerend, met wat de gebruiker kan doen ("schijf vol? rechten op de herstelmap?"). Daarna niet elke 25 s herhalen.

Geen formaatwijziging. De snapshot blijft JSON naast de app-data.

Raakvlakken

lib/services/recovery_service.dart
lib/state/tabs_provider.dart (_autosaveTick, _autosaveInterval)
docs/USER_GUIDE.md (crash recovery) — de belofte die nu onvoorwaardelijk klinkt

## Het probleem Onopgeslagen werk wordt elke 25 seconden als herstelkopie weggeschreven. Faalt dat schrijven (schijf vol, rechten, pad weg), dan gaat het naar het logboek en verder niets. Geen snackbar, geen status, geen "herstel werkt nu niet". Op desktop is crashherstel de belofte: de handleiding zegt dat onopgeslagen werk terugkomt. Wie die belofte vertrouwt en daarna crasht, is het werk kwijt zonder ooit te hebben gehoord dat de vangnetten kapot waren. De browserversie zegt dit wél één keer ("hier is geen herstel"). De desktopversie zwijgt als herstel *onverwacht* uitvalt. Daarnaast: bij een harde kill (`kill -9`, stroom uit) tussen twee ticks ontbreekt de laatste ~25 s sowieso — dat is de inherente kloof van interval-autosave. Dit issue gaat over het *stille* falen van de write, niet over die kloof zelf. ## Hoe het nu werkt `lib/services/recovery_service.dart`, `save`: ```dart } catch (e) { logWarning('RecoveryService.save: write recovery snapshot', e); // Autosave mag nooit de app verstoren. } ``` Bewuste keuze: autosave mag de editor niet laten haperen. Het gevolg is dat de enige waarnemer van falen een logregel is die de gebruiker niet ziet. `recovery_service_test.dart` dekt de happy path en de save/discard-race, niet een schrijffout naar schijf. ## Denkrichting (niet uitgewerkt) Eén stille fout mag in het log. De *eerste* fout in een sessie (of de eerste na een geslaagde write) hoort in de UI: kort, niet blokkerend, met wat de gebruiker kan doen ("schijf vol? rechten op de herstelmap?"). Daarna niet elke 25 s herhalen. Geen formaatwijziging. De snapshot blijft JSON naast de app-data. ## Raakvlakken - `lib/services/recovery_service.dart` - `lib/state/tabs_provider.dart` (`_autosaveTick`, `_autosaveInterval`) - `docs/USER_GUIDE.md` (crash recovery) — de belofte die nu onvoorwaardelijk klinkt

brenno added the

bug

label

2026-09-03 10:14:38 +00:00

brenno added the

in-progress

label

2026-09-03 14:52:56 +00:00

brenno referenced this issue from a commit

2026-09-03 15:16:42 +00:00

fix(recovery): mislukt crashherstel melden aan de gebruiker (#1953)

brenno referenced this issue