Interpret removal markers within their contract
Microsoft Graph delta uses continuation/state links and can return @removed objects. Their reasons can include changed or deleted, so not every marker means destructive erasure. This local ledger records the target action after checking the actual resource’s delta semantics.
| Change | Local check | Checkpoint decision |
|---|---|---|
| R1 updated | Apply current supported fields | Mark disposition complete |
| R2 with removed marker | Confirm reason and local deactivation/removal policy | Do not skip marker silently |
| Final state link returned | All page changes accounted for | Commit opaque link with local state |
Handle an invalidated state token
Do not edit an opaque delta URL to guess a newer timestamp. Use the documented reset/full-resync route if the source rejects state, preserving lifecycle guards. Rebuilding from live records alone can miss identities previously removed unless the reconciliation design covers them.
A deletion marker failed locally, but the final delta link is available. Should it replace the old checkpoint?
Show the worked answer
Only with a durable separate recovery record for that exact marker. Otherwise keep the previous checkpoint and make repeated changes safe to apply; do not lose the unresolved removal.