Letzte Woche ging’s um den Doppelpost-Bug. Diese Woche geht’s um die Lehre daraus, etwas allgemeiner: warum man WordPress-Cron nie blind vertrauen sollte.
Viele denken, `wp-cron.php` sei ein echter System-Cronjob, der zuverlässig alle 60 Sekunden tickt. Ist es nicht. WordPress-Cron ist „pseudo-cron“ — er wird bei jedem Seitenaufruf geprüft und bei Bedarf per Hintergrund-Request ausgelöst. Auf einer stark besuchten Seite heißt das: er läuft oft, manchmal mehrfach fast gleichzeitig. Auf einer wenig besuchten Seite: er kann auch mal eine Weile pausieren.
Für die meisten WordPress-Funktionen ist das egal. Für eine Job-Queue, die Inhalte an eine externe API wie LinkedIn schickt, ist das der Unterschied zwischen „funktioniert“ und „postet zweimal“.
Was ich seit dem Fix anders mache: → Jeder Queue-Durchlauf holt sich zuerst einen Lock (ein Transient mit kurzer Lebenszeit) — läuft schon einer, steigt der zweite sofort wieder aus → Jeder Job wird nach der Verarbeitung sofort als „erledigt“ markiert, nicht erst am Ende des Batches — falls der Prozess mittendrin abbricht, wird nichts doppelt verschickt → Ich prüfe regelmäßig echte Ausführungszeiten in den Logs, nicht nur ob der Job „grundsätzlich lief“
Der Grund, warum ich das hier teile: Wenn ihr selbst mal ein Plugin mit Hintergrundjobs baut — WordPress-Cron ist ein bequemes Werkzeug, aber kein Ersatz für ordentliches Job-Management. Das lernt man einmal, meistens auf die harte Tour.
Schreibe einen Kommentar