VianoBugAnalysis/deploy/capture-worker

wowdiag-worker v0.4 – BugAnalysis-Übergabe

Erweiterung des vorgelegten v0.3-Workers. Die ursprüngliche Queue-Claim-Logik und DB-Struktur bleiben erhalten. Keine Änderung der aktiven config.toml, kein Dienststart und keine Datenbankmigration durch diese Dateien.

Nach erfolgreicher wowdiag-/wowsrc-Erzeugung wird ein Versandauftrag dauerhaft in einer separaten lokalen SQLite-Outbox gespeichert. diagnostic_runs.completed bedeutet weiterhin Erfassung abgeschlossen, nicht Analyse abgeschlossen oder API-Zustellung bestätigt. Die Versandquittung ist über --handoff-status sichtbar. Die API übernimmt den Fall anschließend in ihren eigenen Analyseworker.

Einrichtung

1. Bestehende wowdiag_worker.py sichern und die v0.4-Datei sowie buganalysis_handoff.py nebeneinander installieren. Python 3.11 und PyMySQL bleiben die Voraussetzungen; der HTTP-Client benötigt keine neue Bibliothek.
2. Den Abschnitt aus buganalysis.config.example.toml in die vorhandene Worker-Konfiguration übernehmen. Tatsächliche URL und Projektzuordnung setzen. Der URL muss die Serverwurzel sein; HTTPS ist für entfernte Server erforderlich.
3. Einen Integrationsschlüssel in BugAnalysis für das Projekt erzeugen und im Dienst-Environment als VBA_INTAKE_TOKEN hinterlegen. Unter Linux eine geschützte systemd-EnvironmentFile verwenden; den Schlüssel nicht in Skriptargumente, Repository oder Worker-Logs schreiben. Bestehende Unit um EnvironmentFile ergänzen und anschließend kontrolliert neu starten.
4. SQLite-Outbox und Diagnosearchive bis zur bestätigten Zustellung erhalten. Das Outbox-Verzeichnis muss für den Worker schreibbar sein und einen lokalen Datenträger mit SQLite-Dateisperren verwenden. Die Datei nicht zwischen unabhängigen Installationen teilen.

Ohne aktivierten [buganalysis]-Abschnitt bleibt der bisherige Ablauf erhalten. Das Flag bedeutet ausschließlich Erfassung plus Übergabe; der Worker löst keine Modellanfrage selbst aus. Ein laufender BugAnalysis-Worker kann nach Annahme allerdings sofort eine kostenpflichtige Analyse beginnen.

Wiederholungen und Status

python3 wowdiag_worker.py --config config.toml --handoff-status
python3 wowdiag_worker.py --config config.toml --retry-handoffs

Diese beiden Befehle führen keine Erfassung aus. Der normale Dauerdienst sendet fällige Aufträge vor dem nächsten Capture; --once versucht sie auch danach. Netzwerkfehler, Serverausfälle, temporäre Ablehnungen und fehlende/ungültige Zugangsdaten bleiben pending. Nach Behebung werden dieselben Inhalte mit demselben Idempotenzschlüssel versandt. Auch eine verlorene Erfolgsantwort legt dadurch keinen zweiten Fall an. Es werden keine HTTP-Redirects verfolgt.

Unveränderliche Metadaten, Ziel-URL, Archivpfade und Inhaltsprüfwerte stehen in der Outbox; Zugangsdaten stehen dort nicht. Archivänderung oder endgültiger HTTP- Konflikt wird attention und benötigt Betreiberprüfung. Ein Lease verhindert gleichzeitigen regulären Versand durch mehrere Worker-Prozesse. Ein Prozessabbruch lässt den Auftrag nach Ablauf des Lease erneut versuchen. Es gibt keine automatische Neuerzeugung von Archiven oder ein Zurücksetzen der ursprünglichen Queue-Claims.

Bereits vor dem Update abgeschlossene Erfassungen werden nicht automatisch nachträglich eingesendet. Ein erneuter neuer Auftrag für dieselbe Bug-ID wird von BugAnalysis bewusst abgewiesen, wenn der Fall bereits existiert. Rückgaben nach einem Patch erfolgen über den separaten case_return-Vertrag und nicht durch automatisches Umdeuten neuer Captures.

Der Übergabeumschlag nennt die Bug-ID und den Erfassungs-Commit. Die wirklichen Testerbeobachtungen, Titel und Beziehungen liest der BugAnalysis-Importer direkt aus den unveränderten Archiven. Der Worker erfindet keine Beobachtungen und gibt den Erfassungsstand nicht als Stand der ursprünglichen Fehlermeldung aus.

Lokale Prüfung im BugAnalysis-Checkout

python -m pytest tests/profiles/vcore/test_capture_handoff.py prüft den Versand gegen die echte lokale Intake-API mit synthetischen Archiven. Kein echter Server, keine Cloud- Anfrage, keine Änderung der Diagnose-Queue. Ein Server-Feldtest mit einem neuen Bug und Dienstneustart steht nach der Konfiguration noch aus.