Een lopende baan is nu te volgen #82

Merged

roelof merged 1 commit from lopende-baan-volgen into main

2026-08-06 19:46:29 +02:00

roelof commented

2026-08-06 19:45:41 +02:00

Owner

Closes #68

Je opmerking maakte er een beter ontwerp van dan het issue zelf voorstelde: niet alleen een endpoint, maar het overzichtspaneel dat bij het begin opengaat, de ronde volgt, en na een herstart een lopende baan weer oppikt.

Server

JobService onthoudt wat er loopt en hoe ver (Current), en ProgressStream geeft elke melding door op weg naar zijn eigen response. Zonder dat bestaat de voortgang alleen in die response en verdwijnt hij ermee, terwijl de baan doorloopt.

GET /api/jobs is waarmee een client zonder stroom het terugvindt — 204 als er niets loopt, wat een stille server is en geen fout. De tellingen zijn genormaliseerd tot de drie die elke baan draagt, via IJobProgress op de vijf voortgangsrecords; de Added van de scan valt eruit, want dit beantwoordt hoe ver en niet wat het opleverde.

Speler

Het paneel gaat open bij het begin van een ronde in plaats van aan het eind, en volgt hem: een regel per stap zodra die af is, met de lopende eronder.
Bij het opstarten wordt gekeken of er al iets draait. Zo ja, dan komt het paneel op met wat er loopt en hoe ver, elke seconde bijgewerkt.

Vragen in plaats van luisteren, want het channel waar een baan in rapporteert heeft met opzet één lezer en deze speler is dat niet — de stroom hoort bij wie de ronde startte, en dat proces kan weg zijn. Eén seconde is niets tegen een baan van uren.

Wat niet terug te halen is, is de samenvatting: de tellingen van wat elke stap opleverde gingen mee met de stroom die verdween. Het paneel zegt daarom wat er loopt en hoe ver, en als de baan eindigt zegt het dat en leest de bibliotheek opnieuw — in plaats van een verslag te verzinnen dat het nooit gezien heeft.

Nagelopen

Stroom laten vallen met --max-time, waarna /api/jobs de lopende lijstreparatie meldde en 204 gaf toen hij klaar was. Daarna de speler gestart terwijl de baan al liep:

[INF] Lists has been running on the server since 2026-08-06 17:41:21Z; following it.

En in het venster, van een schermafdruk:

Already running                                        ✕
Lists        started before this window was open
Lists 1 of 25 — Queen — Bohemian Rhapsody

Terzijde bevestigd op diezelfde afdruk: het Top 2000-logo staat in het paneel links, dus #71 doet het ook in het echt.

Closes #68 Je opmerking maakte er een beter ontwerp van dan het issue zelf voorstelde: niet alleen een endpoint, maar het overzichtspaneel dat bij het **begin** opengaat, de ronde volgt, en na een herstart een lopende baan weer oppikt. ## Server `JobService` onthoudt wat er loopt en hoe ver (`Current`), en `ProgressStream` geeft elke melding door op weg naar zijn eigen response. Zonder dat bestaat de voortgang alleen in die response en verdwijnt hij ermee, terwijl de baan doorloopt. `GET /api/jobs` is waarmee een client zonder stroom het terugvindt — **204** als er niets loopt, wat een stille server is en geen fout. De tellingen zijn genormaliseerd tot de drie die elke baan draagt, via `IJobProgress` op de vijf voortgangsrecords; de `Added` van de scan valt eruit, want dit beantwoordt *hoe ver* en niet *wat het opleverde*. ## Speler - Het paneel gaat open bij het **begin** van een ronde in plaats van aan het eind, en volgt hem: een regel per stap zodra die af is, met de lopende eronder. - Bij het opstarten wordt gekeken of er al iets draait. Zo ja, dan komt het paneel op met wat er loopt en hoe ver, elke seconde bijgewerkt. **Vragen in plaats van luisteren**, want het channel waar een baan in rapporteert heeft met opzet één lezer en deze speler is dat niet — de stroom hoort bij wie de ronde startte, en dat proces kan weg zijn. Eén seconde is niets tegen een baan van uren. **Wat niet terug te halen is, is de samenvatting**: de tellingen van wat elke stap opleverde gingen mee met de stroom die verdween. Het paneel zegt daarom wat er loopt en hoe ver, en als de baan eindigt zegt het dat en leest de bibliotheek opnieuw — in plaats van een verslag te verzinnen dat het nooit gezien heeft. ## Nagelopen Stroom laten vallen met `--max-time`, waarna `/api/jobs` de lopende lijstreparatie meldde en 204 gaf toen hij klaar was. Daarna de speler gestart terwijl de baan al liep: ``` [INF] Lists has been running on the server since 2026-08-06 17:41:21Z; following it. ``` En in het venster, van een schermafdruk: ``` Already running ✕ Lists started before this window was open Lists 1 of 25 — Queen — Bohemian Rhapsody ``` Terzijde bevestigd op diezelfde afdruk: het Top 2000-logo staat in het paneel links, dus #71 doet het ook in het echt.

roelof added 1 commit

2026-08-06 19:45:41 +02:00

Een lopende baan is nu te volgen 0ed5fde075

Een baan overleeft zijn client, en dat is met opzet — een scan van uren hoort
niet weg te vallen omdat er een venster dichtgaat. Maar het punt ervan ging
verloren bij de volgende client: die toonde een scanknop die 409 antwoordt en
een statusregel die beweert dat er niets gebeurt, terwijl de server uren
doorwerkt. De voortgang bestond alleen in de stroom die weg was.

JobService onthoudt nu wat er loopt en hoe ver (Current), en ProgressStream
geeft elke melding door op weg naar zijn eigen response. GET /api/jobs is
waarmee een client zonder stroom het terugvindt — 204 als er niets loopt, wat
een stille server is en geen fout. De tellingen zijn genormaliseerd tot de drie
die elke baan draagt, via IJobProgress op de vijf voortgangsrecords; de Added
van de scan valt eruit, want dit beantwoordt hoe ver en niet wat het opleverde.

In de speler gaat het overzichtspaneel nu open bij het begin van een ronde in
plaats van aan het eind, en het volgt hem: een regel per stap zodra die af is,
met de lopende eronder. En bij het opstarten wordt gekeken of er al iets draait;
zo ja, dan komt het paneel op met wat er loopt en hoe ver, en wordt dat elke
seconde bijgewerkt.

Vragen in plaats van luisteren, want het channel waar een baan in rapporteert
heeft met opzet één lezer en deze speler is dat niet — de stroom hoort bij wie
de ronde startte, en dat proces kan weg zijn. Eén seconde is niets tegen een
baan van uren.

Wat niet terug te halen is, is de samenvatting: de tellingen van wat elke stap
opleverde gingen mee met de stroom die verdween. Het paneel zegt daarom wat er
loopt en hoe ver, en als de baan eindigt zegt het dat en leest de bibliotheek
opnieuw in plaats van een verslag te verzinnen dat het nooit gezien heeft.

Nagelopen tegen een testserver: stroom laten vallen met --max-time, waarna
/api/jobs de lopende lijstreparatie meldde en daarna 204 gaf toen hij klaar was.
En met de speler erop, gestart terwijl de baan al liep:

  [INF] Lists has been running on the server since ...; following it.

met in het paneel:

  Already running
  Lists      started before this window was open
  Lists 1 of 25 — Queen — Bohemian Rhapsody

Closes #68

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

roelof merged commit 3c05e21fef into main

2026-08-06 19:46:29 +02:00

roelof deleted branch lopende-baan-volgen

2026-08-06 19:46:29 +02:00

roelof referenced this pull request from a commit

2026-08-06 19:46:30 +02:00

Merge pull request 'Een lopende baan is nu te volgen' (#82) from lopende-baan-volgen into main