Sync hängt oder ist “pending” für immer

Ein Sync der Sekunden dauern sollte und stattdessen Minuten bei pending sitzt ist einer der verwirrenderen Failure-Modes — Dashboard sagt “working”, Site ist alive, nichts passiert. Decision-Tree:

Quick-Diagnose

Site-Detail → Activity → Latest sync job. Schau auf:

• Status — pending, running, failed, completed
• Started at — wie lange her?
• Sections — welche Teile gequeued

Wenn Job über 60 Sekunden in pending, etwas ist falsch. Healthy pending Lifetime ist unter 5 Sekunden.

Häufige Ursachen (nach Häufigkeit)

1. WordPress-Site nicht erreichbar (~50%). Site ging offline zwischen Sync-Trigger und Worker-Pickup. Check Site → Health → Last heartbeat — wenn rot oder älter als 15 Min, Site ist offline. WP-Host restarten, dann Retry sync.

2. WP-Cron deaktiviert und kein Traffic (~20%). Hubbees Plugin polls alle 30-60s via WP-Cron. Wenn WP-Cron deaktiviert (define('DISABLE_WP_CRON', true) ohne Alternative) und kein Human-Traffic auf Site, Plugin picked Job nie auf. Fix:

• System-Cron adden: * * * * * curl https://your-site.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
• Oder DISABLE_WP_CRON aus wp-config.php entfernen
• Oder beliebige Seite auf der Site einmal besuchen — triggert WP-Cron sofort

3. Job-Worker-Capacity erschöpft bei Scale (~10%). Bei High-Volume Hubbee-Event (AppSumo Launch-Day, Bulk-Update auf vielen Sites), Worker-Queue kann backupen. Workers laufen mit MAX_CONCURRENT_HTTP = 80. Wenn Dashboard hunderte Jobs in pending zeigt, dein Job wird picked up — einfach warten. 99th-Percentile-Wait ist unter 5 Minuten.

4. Stale Command pinning Sync (~10%). Vorheriges silent-failed Command kann Sync-Section in running indefinitely halten. Activity → Commands → Filter status: running, älter als 60 Min — wenn Rows erscheinen, sind stuck. Jeden → Force cancel. Dann frischen Sync triggern.

5. Plugin-Version zu alt (~5%). Job-Worker tracked Mindest-Plugin-Version. Wenn dein Plugin älter, Job sitzt in pending weil Worker keinen Inkompatibilität-Plugin beliefert. WP-Admin → Plugins → Hubbee → Update Now. Site re-handshaked innerhalb 60s nach Update.

6. Network-Glitch auf Hubbee-Seite (selten). Edge-Function-Timeouts, transient Supabase-Errors, Regional-Outages. Check Status-Page — wenn etwas rot, sit tight; Worker retried automatisch.

Stuck-Job force-canceln

Wenn Job über 15 Min pending und obige Causes nicht greifen:

1. Site-Detail → Activity → Sync jobs
2. Stuck-Job-Row finden
3. Drei-Punkt-Menü → Force cancel

Job moved zu Status cancelled. Frischen Sync sofort triggerbar — neuer Job ist independent.

Force-Cancel ist safe: WordPress auf anderer Seite bekommt cancelled Command gar nicht (nie delivered). Kein Half-Applied-State.

Self-Test

WP-Admin → Hubbee → Diagnostics → Self-Test runs gleiche Probes wie Onboarding-Diagnostic plus “can-I-claim-a-job”-Check. Pin Result wenn du Support kontaktierst — wir können Failure präzise mappen.

Wiederholung verhindern

• System-Cron statt WP-Cron (häufigste vermeidbare Ursache)
• Hubbee-Plugin updated halten — Auto-Update via WP-Admin reliable
• Hosting in Region nahe deinem Team (Latency-Timeouts shrinken)
• Für Staging-Sites die selten besucht: Uptime-Ping alle 5 Min via UptimeRobot / Better Stack — hält WP-Cron firing