Probleme beim Upload von älteren Testdateien

[schumaki]

Beschreibung

Elisabeth beschreibt, dass beim Hochladen von XML-Dateien der Verlinkungsaufgaben in VERA3-Deutsch immer wieder Fehlermeldungen auftauchen, dass einige XML-Dateien beim Hochladen fehlschlagen (XSD validation failed, angezeigt werden sie dann aber trotzdem).

Wahrscheinlich im Zusammenhang mit diesen Problemen in den XML-Dateien steht, dass bei manchen Aufgaben (z. B. DHB003 und DLB022) die falsche Seite im Replay angezeigt wird. Für diese Aufgaben hat sie auch schon probiert, den Schemer auf 2.7.0 zu aktualisieren, dann eine Seite einzutragen und anschließend die vocs-Datei in der Kodierbox zu überschreiben.

Erwartetes Verhalten

• fehlgeschlagene Uploads sollten nicht angezeigt werden
• wir bräuchten eine instruktivere Anzeige (entweder in der Kodierbox oder über ein Wiki/FAQ/sonstiges), wie solche Fehler dann aufgelöst werden können

Reproduktionsschritte/Beispiele

Die beiden Bsp.-Aufhaben sind hier abgelegt: "T:\Elisabeth\an TBA". Die XML, VOMD und VOUD kommen aus der älteren ZIP-Datei (11.5.) und die VOCS aus der neueren ZIP-Datei. Durch unterschiedliche Versionen von Player, Editor und Schemer (in BistaTest und in VERA3) war das der einfachste Weg.
Die Aufgaben liegen im Studio im Bereich "VERA DeP: Verlinkungsaufgaben", aber die ZIP-Dateien beinhalten alle Aufgaben, die betroffen sind.

In der Kodierbox liegen die Aufgaben im Arbeitsbereich "VERA DeP Pilo 2026 (Les+Hör)" auf dem Produktivserver. Dort wird bei DLB022_09 die Seite von DLB022_10 angezeigt, bei DHB003 fehlt Basisvariable 02 komplett, dafür ist auf 04 anscheinend eine manuelle Kodierung hinterlegt (CODING_INCOMPLETE). Beides passt nicht zum aktuellen Kodierschema (.vocs).

---

Versionen

• Verwendete Schemer- und Kodierboxversion:
  • Player & Editor 2.12.4
  • Schemer 2.7.0
  • Kodierbox 1.16.2
• Betriebssystem: Windows (HU-Rechner)
• Browser: Firefox Version 152

Weitere Informationen

Es gab auch vorher schon ein Problem mit einigen XML-Dateien und dem Hochladen in das Testcenter (als Hintergrundinfo).

[jurei733]

Analyse der bereitgestellten Dateien:

• Die XSD-Fehler lassen sich lokal reproduzieren. Im Stand 2026-06-17 Verlinkungsaufgaben mit Player und neuer Kodierung sind DLB004.xml und DLB022.xml gegen vo_Unit.xsd aus testcenter/17.4.1 ungültig.
• Konkret kollidieren DerivedVariables mit BaseVariables:
  • DLB004.xml: doppelte Variable 08 (Duplicate key-sequence ['08'])
  • DLB022.xml: doppelte Variable 04 (Duplicate key-sequence ['04'])
• Im älteren Stand 2026-05-11 studio unit download sind die XMLs gültig. Dort heißen die entsprechenden DerivedVariables noch _08 bzw. _04, kollidieren also nicht.
• Die fehlgeschlagenen XMLs werden im regulären XML-Uploadpfad nicht gespeichert. Sie erscheinen nur im Upload-Ergebnisdialog unter „Fehlgeschlagen“. Das ist aus meiner Sicht sinnvoll, sollte aber klarer angezeigt werden.
• Die aktuell angezeigten Fehler können nach dem Konflikt-/Überschreibdialog doppelt auftauchen, weil Fehler aus erstem Uploadversuch und Überschreibversuch zusammengeführt werden.
• Der falsche Replay-Sprung ist ein separates Problem: Bei DLB022.vocs kollidieren id und alias in der Page-Map. Beispiel: id=08 alias=09 page=10 und später id=09 alias=10 page=11. Da die Kodierbox momentan id und alias in dieselbe Map schreibt, kann der spätere Eintrag den Alias 09 überschreiben. Dadurch landet DLB022_09 auf der Seite von DLB022_10.

Geplanter Fix:

• Upload-Ergebnisdialog behält fehlgeschlagene Uploads bei, dedupliziert sie aber über Dateiname und Grund.
• XSD-Fehler werden detaillierter zurückgegeben und angezeigt, z. B. mit betroffener Variable/Zeile statt nur XSD validation failed: <datei>.
• XML-Dateien werden robuster als XML behandelt, auch wenn sie als application/octet-stream ankommen.
• Replay-Page-Mapping wird so angepasst, dass id und alias nicht mehr unbeabsichtigt kollidieren. Ziel ist, sichtbare Response-Variablen wie DLB022_09 stabil auf die korrekte Seite aufzulösen.
• Zusätzlich Tests für die XSD-Fehlerdarstellung, Deduplizierung und den DLB022_09-Replay-Fall.

[schumaki]

Ergänzung von Elisabeth: DHB023 Item 10, da wird Item 11 angezeigt.

Bei DHB003 ist seltsam, weil die ID im Studio 02 ist und die Kodierung auch als 02 angelegt, weshalb ich mir nicht erklären kann, wieso es in der Kodierbox unter 04 läuft.
Dort wird für Basisvariable 02 keine Werte angezeigt und auf 04 anscheinend eine manuelle Kodierung hinterlegt (CODING_INCOMPLETE).
Woran kann das liegen?

Bei DLB022.vocs kollidieren id und alias in der Page-Map. Beispiel: id=08 alias=09 page=10 und später id=09 alias=10 page=11

Hm, interessant. Wie wird die ID denn festgelegt? Kann ein Studio-Nutzer das überhaupt in der UI ändern? Oder nur den Alias.

[jurei733]

Danke fuer die Ergaenzung. Ich habe die genannten Dateien lokal noch einmal gegen die VOCS/XML-Struktur geprueft.

• DHB023 passt sehr gut zum gleichen Page-Map-Problem wie DLB022: In DHB023.vocs steht u. a. id=09 alias=10 page=11 und direkt danach id=10 alias=11 page=12. Wenn id und alias in dieselbe Page-Map geschrieben werden, kann der spaetere technische Eintrag id=10 den sichtbaren Alias 10 ueberschreiben. Dann landet Item/Variable 10 im Replay auf der Seite des folgenden Items.
• DHB003 sieht nach einem etwas anderen, aber verwandten ID/Alias-Thema aus. In den exportierten Dateien gibt es fuer die sichtbare 02 keine technische id=02; dort steht id=04 alias=02 (DHB003.vocs und DHB003.xml). Zusaetzlich gibt es spaeter id=07 alias=04. Damit kommt 04 in zwei Rollen vor: einmal als technische ID der sichtbaren 02, einmal als sichtbarer Alias eines spaeteren Items. Das kann erklaeren, warum unter 02 keine Werte erscheinen, waehrend unter 04 ein manueller Kodierstatus wie CODING_INCOMPLETE sichtbar wird: Die Kodierbox vermischt bzw. zeigt an der Stelle vermutlich technische ID und sichtbaren Alias nicht sauber getrennt.
• Zur Studio-Frage: Aus dem Exportbild wuerde ich id als technische Verona-/Element-ID lesen und alias als sichtbare bzw. fachliche Variablenbezeichnung. Ich wuerde daher nicht davon ausgehen, dass ein Studio-Nutzer die technische id im normalen UI frei aendert; vermutlich wird der Alias/sichtbare Name gepflegt. Das sollte aber noch einmal gegen Studio bestaetigt werden.

Konsequenz fuer die Kodierbox: id und alias duerfen nicht als gleichwertige Schluessel in derselben Lookup-Logik kollidieren. Fuer Replay muss die sichtbare Variable stabil auf die richtige Seite fuehren (DHB023/DLB022), und fuer die Anzeige/Kodierstatus sollte intern die technische ID erhalten bleiben, aber nach aussen klar der Alias sichtbar sein (DHB003).

[jurei733]

Kurzfassung der finalen Änderungen:

• Upload-Feedback verbessert: fehlgeschlagene XML-Uploads können jetzt Details inkl. XSD-Zeilenmeldungen anzeigen; doppelte Fehlereinträge werden im Ergebnisdialog und im Snackbar-Zähler dedupliziert.
• UX-Hinweise ergänzt: der Upload-Ergebnisdialog zeigt bei typischen Fehlern kurze Handlungshinweise, z. B. bei Duplicate key-sequence den Hinweis auf doppelte Variable-/Element-IDs oder Aliase.
• Aufgeräumt: die alte, nicht mehr verwendete TestFilesUploadFailedDialogComponent wurde entfernt; fehlgeschlagene Uploads laufen jetzt nur noch über den Ergebnisdialog.
• Replay-/Variablen-Mapping korrigiert: bei id/alias-Kollisionen gewinnt der öffentliche Alias, sodass z. B. Alias 09 auf die intendierte Seite zeigt und nicht versehentlich die Page-Zuordnung einer kollidierenden internen id übernimmt.
• Validierung: fokussierter Frontend-Test, Frontend-Lint und git diff --check liefen nach der Nachbesserung grün.