---
title: "Cancellation Succeeded but Local State Stale"
description: "Diagnose cases where provider cancellation succeeded but local booking state stayed stale across webhook, persistence, ordering and reconciliation layers."
slug: "cancellation-local-state-stale-troubleshooting"
translationKey: "troubleshooting-cancellation-local-state-stale"
locale: "en"
type: "troubleshooting"
category: "troubleshooting"
tags: ["cancellation","stale-state","webhook","reconciliation","booking"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
---

When provider cancellation succeeds while local booking remains CONFIRMED, the failure is usually in **state propagation and evidence processing**.

## Symptom

The provider booking is cancelled but local UI still shows confirmed, refund flow does not trigger, or webhook/reconciliation evidence never updates local state.

## Possible causes

Cancellation response not persisted, lost webhook, stale event rollback, optimistic-concurrency conflict, or event-store/materialized-view divergence.

## Diagnosis

Inspect the cancellation attempt, verify authoritative provider state, compare event store with materialized state, check webhook/queue/DLQ, inspect failed writes/version conflicts and verify downstream payment/refund dependencies.

## Recovery

When authoritative provider state is CANCELLED, repair local state using reconciliation evidence while preserving the original event history and root-cause markers.

## Prevention

Use transactional outbox, versioned state updates, reconciliation fallback, stale-state detectors and event/materialized-state consistency checks.

## Observability

Track provider/local drift, cancelled-but-local-confirmed count, propagation latency, reconciliation repairs and failed materialization updates.