Malin
296693ebd4
Root cause of the 2-hour stall: a category page's PHP process hung (CLI-run cron processes typically have no execution time limit) and never returned, so it never reached the code path that marks a page complete, queues the next page, or marks the run failed. Action Scheduler's own watchdog eventually marked the action failed after its 3600s timeout, but by then the plugin's own run-tracking option was permanently stuck at status=running with no further pages ever queued - and since manual and scheduled syncs both check the same lock, this silently blocked all future syncs (not just this one) for the full 4-hour lock safety-net. Adds an 'updated_at' timestamp refreshed on every batch/page, and checks it in queue_full_sync(): if a "running" sync hasn't made progress in over 10 minutes, treat it as abandoned, clear the lock, and start fresh instead of waiting out the multi-hour safety-net. Also caps the 429 retry-after sleep at 30s rather than trusting an external API-supplied value without bound, as a defensive measure against another unbounded stall. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>