Autocoding 1 nach Rücksetzen lässt sich nicht über Hinweismeldung starten

[schumaki]

Beschreibung

Nachdem ich den 1. Autocoderlauf zurückgesetzt habe, kommt eine Hinweismeldung (sehr schön, übrigens!), dass 78649 Aufgabenbearbeitungen ein Autocoding benötigen. In einem praktischen Button wird angeboten, das zu starten. Wenn ich darauf klicke, kommt allerdings eine Fehlermeldung:

Fehler

Auf dem Server ist ein Fehler aufgetreten. Bitte versuchen Sie es erneut.
Fehler-ID: 0fb457c9-aaea-4a7e-9132-eb8ecc164c7b
Status: 500
Zeitpunkt: 16.06.2026 10:28:37
Servermeldung: Internal server error
Anfrage: POST api/admin/workspace/12/coding/freshness/code 

Über den Button Automatisch Kodieren oben links lässt sich der Autocoderlauf jedoch starten.

Erwartetes Verhalten

• Der Button in der Hinweismeldung sollte den Autocoderlauf starten
• noch besser fände ich, wenn sich danach das Fenster "Testgruppen Kodieren" öffnet und den gerade gestarteten Lauf als laufenden Auftrag anzeigt.

Reproduktionsschritte

s. o.

Beispiele

• VERA_3_TEST auf dem Testserver

---

Versionen

• Kodierboxversion 1.16.1

[jurei733]

Kurze Fehleranalyse: Der Hinweis-Button nutzt POST /api/admin/workspace/:id/coding/freshness/code. Dieser Pfad ermittelt vor dem Queue-Start den kompletten Freshness-Scope und reicht große unitIds in mehrere TypeORM-Abfragen mit expandiertem IN (:...unitIds) weiter, u. a. in CodingProcessService.codeUnitIds und CodingReadinessService.

Bei VERA_3_TEST mit ca. 78k betroffenen Aufgabenbearbeitungen kann das sehr wahrscheinlich die SQL-Parameter-/Query-Grenzen sprengen und als 500 enden. Der normale Button „Automatisch Kodieren“ funktioniert vermutlich deshalb, weil er über den Personen-/Gruppenpfad startet und diese große Unit-ID-Vorabselektion nicht in derselben Form ausführt.

Naheliegender Fix: die großen Unit-ID-Filter im Freshness-/Readiness-Startpfad auf Array-Parameter wie = ANY(:unitIds) oder Chunking umstellen und mit einem Large-Scope-Test absichern.

[jurei733]

PR #762 ist gemerged. Kurz zur Änderung:

• Die Autocoding-Freshness-Pfade verwenden für große Scopes jetzt array-gebundene ANY(:ids)-Filter statt expandierter IN (:...ids)-Listen. Dadurch werden bei vielen Personen/Booklets/Units nicht mehr extrem viele SQL-Parameter erzeugt.
• Betroffen sind die Scope-Abfragen in CodingProcessService und CodingReadinessService, also genau die Vorprüfung und Job-Erzeugung für den Start über den Freshness-Hinweis.
• Ergänzt wurden Unit-Tests, die die neuen Query-Fragmente und gebundenen Array-Parameter absichern; Backend-Lint und Backend-Tests liefen grün.

Das Issue lasse ich bewusst offen, bis die Änderung auf der Zielumgebung noch einmal mit den großen Testdaten bestätigt wurde.

[jurei733]

Umgesetzt in #765.

Kurzüberblick der Änderungen:

• Der Button im Hinweisbereich startet den Freshness-Auto-Coding-Lauf und öffnet anschließend den Dialog „Testgruppen Kodieren“ direkt mit dem gestarteten Job.
• Der Dialog zeigt den laufenden Job über die bestehende Job-Status-Anzeige und gibt beim Schließen den zuletzt beobachteten Jobstatus zurück.
• Der Parent pollt nach dem Schließen nur weiter, wenn der Job noch nicht terminal ist. Terminale Zustände wie completed, failed, cancelled oder paused starten kein doppeltes Polling.
• Auto-Coding-Completion-Events tragen jetzt optional die Job-ID, damit andere Jobs den aktiven Freshness-Job im Parent nicht versehentlich aus dem Tracking werfen.
• Ergänzende Frontend-Tests decken Dialogstart, Dialogschluss, terminale Status und fremde Completion-Events ab.