Zum Inhalt

1:1-Spiegel aus dem Repo

Quelle: zulieferung/incidents/W6_INCIDENT_20260807_SHOPIFY_STOCKJOBS_JOBFOUNDDEAD.md · Stand der Quelldatei: 08.08.2026 09:35 · erzeugt: 14.08.2026 00:33 Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.

INCIDENT 20260807 — Shopify-Bestandsexport-Jobs sterben wiederholt (JobFoundDead), heilen sich nach ~2h selbst

Severity: MITTEL · Status: BEOBACHTEN · Entdeckt von: M (Shopify-Meldung 07.08. 01:00) · Diagnose: G · Loesung: siehe Datei (Job e9da54ba: verwerfen, nicht requeuen — M offen)
Status ZU (07.08. 02:53 alle done) — Ursache OFFEN bei sandas.lt-Nacharbeit
Aufgetreten 07.08. 01:00 · Entdeckt: 01:55 durch M (Jobs-Ansicht)
System Odoo queue_job (Kanal root) · sale.integration SHOPIFY2
Symptom "Export Stock to Stores (3)" Failed in der Jobs-Ansicht; (1)/(2) pendeln zwischen pending/started
Auswirkung Bestands-Sync zu Shopify um ~2h verzoegert; keine Kundenwirkung
Fallbeispiel Jobs 2334915-2334918 (UUID 4cec9e06... = Nr. 3)

1. Zeitachse (Berlin)

  • 01:00:13 — vier Geschwister-Jobs "Export Stock to Stores (1)-(4)" angelegt
  • 01:16 — (4) laeuft in 29 s sauber durch (retry 2)
  • 01:00-02:53 — (1)-(3) sterben wiederholt: exc JobFoundDead, retry-Zaehler bis 178 (!) ueber max_retries 5 hinaus — der Dead-Job-Cron requeued Gestorbene immer neu
  • 02:52-02:53 — alle drei laufen durch; Reihe komplett done (Fruehlage-Beleg exec 8065)

2. Ursachenkette

  1. JobFoundDead = der ausfuehrende Odoo-Worker starb MITTEN im Job (Zeitlimit limit_time_real oder Worker-Recycling) — kein Fach-, sondern ein Ressourcenfehler.
  2. Grosse Stock-Export-Jobs + nächtliche Cron-Last auf demselben root-Kanal -> wiederholtes Sterben, bis Last sank.
  3. retry>max_retries zeigt: JobFoundDead-Requeues umgehen die max_retries-Logik — die Reihe kann im Extremfall ENDLOS pendeln, ohne dass jemand alarmiert wird.

3./4. Loesung

Selbstheilung abgewartet (richtig: nachts kein Eingriff noetig); KEIN manueller Requeue erforderlich. Dauerhaft (sandas.lt-Nacharbeitsliste): Worker-Limits vs. Jobgroesse pruefen (limit_time_real fuer queue-Worker), Stock-Export ggf. in kleinere Batches; JobFoundDead-Zaehler beobachten.

5. Erkennung kuenftig

  • Jobs-Ansicht Filter Failed + exc_name=JobFoundDead; verdaechtig ab retry > max_retries
  • kw/JSON-2: queue.job search_read [["state","=","failed"]] fields id,name,exc_name,retry — gehoert in die D-049-Status-Seite (M-Vorgabe: Jobqueue-Ueberwachung)

6. Lessons

  1. JobFoundDead + hoher retry = Ressourcen-, kein Datenproblem; erst beobachten, nicht requeuen.
  2. Verwandter Fall am selben Tag: Job e9da54ba (Reship-Validierung) — failed-Leiche, deren Picking laengst done war -> VERWERFEN statt requeuen. Merksatz: Vor jedem Requeue den Zielzustand des Objekts pruefen.