Skip to documentation content

Troubleshooting

Recover iCal sync and stale inventory

Use source health, retry and snapshot rules to diagnose stale iCal occupancy without releasing blocks or duplicating reservations.

Start with the source label, room, status, last success, next due time, failure class and source revision. The default interval is 30 minutes; WordPress cron is best effort and a real cron runner is recommended. Verify the hb_pro_ical_sync_tick schedule and that only active, due sources are selected, without exposing the feed URL. Check TLS, HTTPS validation, timeout, redirect, size, event, line and horizon limits before treating a fetch as healthy.

A transient failure retries with backoff; configuration or parser failures are recorded for later attention. Every failed or partial feed preserves the last known-good full snapshot. The last known-good snapshot is the recovery anchor. It must never release occupancy, clear an external_block or create a partial commit. A valid empty calendar releases only that source’s active blocks. Same-source UIDs are idempotent, and a source revision or license change aborts a stale worker before commit.

If inventory appears blocked after a Pro deactivation or license loss, that is intentional safety behavior: existing external blocks remain read-only and enforced. Do not delete them from the database or mark them as website bookings; resolve the source on the OTA and restore the entitlement before a new fetch.

Escalate with health timestamps, bounded error class, revision and block counts. Redact URLs, tokens, guest data and raw feed bodies from every attachment.

Was this article helpful?

Your feedback helps us improve the documentation.