Geen manier om te zien hoe ver een lopende baan is als de voortgangsstroom wegvalt

roelof commented

2026-08-06 13:03:35 +02:00

Owner

Een scanronde duurt uren. Raakt de client onderweg zijn voortgangsstroom kwijt — het venster dicht, het netwerk hikt, de laptop in slaap — dan meldt de server netjes

A progress stream was dropped by its client; the job runs on.

en dat "runs on" klopt: de baan loopt door, en dat is met opzet zo. Alleen is er daarna geen enkele manier meer om te zien hoe ver hij is.

De voortgang bestaat alleen in de SSE-stroom. ProgressStream leest een channel leeg naar de response; wat eruit gaat wordt nergens bewaard.
IJobService weet wél dát er iets draait (IsRunning), maar niet wat en niet hoe ver.
POST /api/jobs/cancel is het enige baan-endpoint dat er is. Opnieuw op de scanknop drukken geeft 409.

Vandaag is de enige uitweg het resultaat aflezen aan de bibliotheek zelf — GET /api/collections voor de tellingen, en voor de lijstreparatie tellen hoeveel tracks hun lijstnaam al kwijt zijn. Dat werkt, maar het is raden op basis van bijwerkingen, en het is per stap iets anders.

Voorstel: `GET /api/jobs`

JobService onthoudt drie dingen van de lopende baan:

welke het is (scan, fill, lijstreparatie, albumreparatie, artiestfoto's)
wanneer hij begon
de laatste voortgangsmelding die er langskwam

ProgressStream legt die laatste melding daar neer op precies het moment dat hij hem ook naar de response schrijft — één regel, en het is toch al de plek waar elke melding langskomt. Het endpoint antwoordt dan met dat drietal, of met "er loopt niets".

Wat dat oplevert:

curl volstaat om te zien hoe ver een scan is, ook als er geen client meer aan hangt.
De speler kan er weer op aansluiten. Dat is het punt waar het uiteindelijk om gaat: een stroom die wegvalt bij een baan van uren hoort geen verloren middag te betekenen. Bij het starten, of na een mislukte stroom, kan de speler GET /api/jobs vragen en de voortgangsregel weer oppakken — nu staat hij daar met een lege statusbalk terwijl de server vrolijk doorwerkt.
De 409 die je nu krijgt als je opnieuw op scan drukt, kan dan iets nuttigers zeggen dan "er loopt al iets".

Aandachtspunten

Aansluiten is niet hetzelfde als de stroom delen. De channel heeft SingleReader = true en dat is goed zo; het voorstel is niet om een tweede lezer toe te laten, maar om de laatste melding op te vragen. Wil de speler een lopende regel, dan is dat pollen — één verzoek per seconde is voor een baan van uren ruim genoeg.
De vorm van een voortgangsmelding verschilt per baan: de scan heeft Done/Total/Added/Current, de andere Done/Total/Current. Het endpoint kan het beste de laatste melding doorgeven zoals hij is, plus welke soort baan het is, en de client laten weten wat hij ermee moet.
Het samenvattingsresultaat is een aparte vraag. Wie de stroom kwijtraakt mist ook de result aan het eind, en daarmee het overzichtspaneel uit #57. Dat zou met hetzelfde mechanisme te redden zijn — de laatste afgeronde baan en zijn resultaat onthouden — maar het is een tweede stap en hoeft niet in één keer.
Het endpoint hoort in CurateApi, achter dezelfde adminpolicy als jobs/cancel.

Een scanronde duurt uren. Raakt de client onderweg zijn voortgangsstroom kwijt — het venster dicht, het netwerk hikt, de laptop in slaap — dan meldt de server netjes ``` A progress stream was dropped by its client; the job runs on. ``` en dat "runs on" klopt: de baan loopt door, en dat is met opzet zo. Alleen is er daarna **geen enkele manier meer om te zien hoe ver hij is.** - De voortgang bestaat alleen in de SSE-stroom. `ProgressStream` leest een channel leeg naar de response; wat eruit gaat wordt nergens bewaard. - `IJobService` weet wél dát er iets draait (`IsRunning`), maar niet wat en niet hoe ver. - `POST /api/jobs/cancel` is het enige baan-endpoint dat er is. Opnieuw op de scanknop drukken geeft 409. Vandaag is de enige uitweg het resultaat aflezen aan de bibliotheek zelf — `GET /api/collections` voor de tellingen, en voor de lijstreparatie tellen hoeveel tracks hun lijstnaam al kwijt zijn. Dat werkt, maar het is raden op basis van bijwerkingen, en het is per stap iets anders. ## Voorstel: `GET /api/jobs` `JobService` onthoudt drie dingen van de lopende baan: - **welke** het is (scan, fill, lijstreparatie, albumreparatie, artiestfoto's) - **wanneer** hij begon - de **laatste voortgangsmelding** die er langskwam `ProgressStream` legt die laatste melding daar neer op precies het moment dat hij hem ook naar de response schrijft — één regel, en het is toch al de plek waar elke melding langskomt. Het endpoint antwoordt dan met dat drietal, of met "er loopt niets". Wat dat oplevert: - `curl` volstaat om te zien hoe ver een scan is, ook als er geen client meer aan hangt. - **De speler kan er weer op aansluiten.** Dat is het punt waar het uiteindelijk om gaat: een stroom die wegvalt bij een baan van uren hoort geen verloren middag te betekenen. Bij het starten, of na een mislukte stroom, kan de speler `GET /api/jobs` vragen en de voortgangsregel weer oppakken — nu staat hij daar met een lege statusbalk terwijl de server vrolijk doorwerkt. - De 409 die je nu krijgt als je opnieuw op scan drukt, kan dan iets nuttigers zeggen dan "er loopt al iets". ## Aandachtspunten - **Aansluiten is niet hetzelfde als de stroom delen.** De channel heeft `SingleReader = true` en dat is goed zo; het voorstel is niet om een tweede lezer toe te laten, maar om de laatste melding op te vragen. Wil de speler een lopende regel, dan is dat pollen — één verzoek per seconde is voor een baan van uren ruim genoeg. - **De vorm van een voortgangsmelding verschilt per baan**: de scan heeft `Done/Total/Added/Current`, de andere `Done/Total/Current`. Het endpoint kan het beste de laatste melding doorgeven zoals hij is, plus welke soort baan het is, en de client laten weten wat hij ermee moet. - **Het samenvattingsresultaat is een aparte vraag.** Wie de stroom kwijtraakt mist ook de `result` aan het eind, en daarmee het overzichtspaneel uit #57. Dat zou met hetzelfde mechanisme te redden zijn — de laatste afgeronde baan en zijn resultaat onthouden — maar het is een tweede stap en hoeft niet in één keer. - Het endpoint hoort in `CurateApi`, achter dezelfde adminpolicy als `jobs/cancel`.

roelof commented

2026-08-06 17:21:42 +02:00

Author

Owner

Is het een idee om de voortgang in het samenvattings venster bij te houden. Dat die dus opend bij het begin en de voortgang en eventuele problemen meldt. Natuurlijk moet de scan wel doorlopen als de client gesloten wordt. Als de client daarna weer geopend graag kijken of er een job loopt en zo ja, de voortgang tonen in het venster

roelof referenced this issue from a pull request that will close it,

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

Een lopende baan is nu te volgen #82

roelof referenced this issue from a commit

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

Een lopende baan is nu te volgen

roelof added reference lopende-baan-volgen

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

roelof closed this issue

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