# Subscription conformance and recovery

The `0.1.0-dev.5` reference implementation verifies optional notification delivery against the current Host grant. These cases explain what a Host or requester implementer should reproduce. They complement the [subscription contract](subscriptions.md), [synchronization profile](synchronization.md) and [migration recovery rules](migration-conformance.md).

## Executable cases

Fourteen focused tests in [subscriptions.test.ts](../tests/subscriptions.test.ts) use synthetic keys and encrypted exchanges. They check behavior at the protocol and persistence boundaries, rather than treating an HTTP success as permission or callback proof.

| Case | Expected result |
| --- | --- |
| Scope, patient, lifetime, retry and quota | Invalid patient/topic/lifetime fails; identical registration returns the original pending state; changed ID input conflicts; ten live/recent registrations cap further work for that requester/patient. |
| Callback ownership and key binding | Wrong challenge acknowledgment or application key cannot activate; unexpected ID and wrong callback fail at the receiver. |
| Atomic visible-change scheduling | Unrequested topics/other patients produce no signal; duplicate writes produce no new work; rolled-back changes roll back their outbox changes. |
| Lost acknowledgment and restarts | Host retains the same logical delivery after Host/receiver restart; receiver commits only one pull task; reply envelopes remain fresh. |
| Concurrent change and pull completion | A write during delivery creates subsequent work; completing an older inbox revision cannot erase a newer one. |
| JWT expiry versus lasting authority | A valid continuing grant survives short JWT expiry; grant revocation/subscription expiry prevent callback preparation and contact. |
| Representatives and rotation | Withdrawn representative permission and planned dual-key rotation suspend old callbacks before any transport call. |
| Stale trust | Missing fresh evidence pauses with retry; fresh evidence resumes the same pending work. |
| Destination constraints | URL credentials/query/fragment and HTTP fail; private/reserved/mapped/transition addresses and a nonstandard public port are rejected. |
| Cancellation, challenge expiry, authority race | Cancellation remains terminal; expired challenge suspends; revocation during destination preparation blocks sending. |
| Catch-up and retention | Authorized feed retrieves ordered changes; a lost retained interval requires a fresh scoped snapshot. |
| Host migration release | A real source release blocks source delivery; destination activation imports no subscription credentials or authority. |
| Shared database delivery lease | Two live Host instances sharing the database cannot send the same unexpired leased job concurrently. |
| Credential revocation and receiver pins | Known credential revocation blocks pending delivery; reopening a receiver database under a different Host fails. |

These are fourteen test functions; some contain multiple assertions/scenarios. The overall suite now has 104 passing tests. Tests do not certify exhaustive network range coverage, actual Internet DNS rebinding attacks, prolonged outage behavior or independent vendor implementation.

## Failure recovery

| Failure point | Durable state and next action |
| --- | --- |
| Registration response lost | Retry the same subscription ID and identical input using a fresh envelope. |
| Challenge request/reply lost | Retry within the original deadline; receiver repeats the same challenge acknowledgment. |
| Host crashes after claiming delivery | Wait for lease expiry, then retry its stable logical delivery ID. |
| Receiver crashes before commit | Host receives no valid acknowledgment and retries; no task was accepted. |
| Receiver commits but reply is lost | Stable delivery receipt survives; retry acknowledges without creating a second task. |
| Host sees acknowledgment but a newer change exists | Preserve outbox work, choose a new delivery ID and send another hint. |
| Application crashes after callback acknowledgment | Durable receiver inbox survives; resume authorized pull on restart. |
| New notification arrives during a pull | Inbox revision changes; old completion does not delete newer work. |
| Feed cursor expires or retention removes history | Obtain a fresh scoped snapshot, durably replace mirror/cursor, then finish matching inbox work. |
| Fresh authority status unavailable | Send nothing; obtain fresh evidence and retry within existing authority. |
| Authority withdrawn or source retired | Discard delivery work and keep registration suspended; do not silently renew or redirect. |

## Operator boundaries and release gates

The reference Host runs its delivery worker explicitly; production scheduling, monitoring and secure storage are operator integrations. Its privileged transport factory is the only private-network exception and must be configured outside requester-controlled input. Production gates include an independently reviewed destination policy, resolver deadlines, socket/egress constraints, jitter/backpressure, bounded cleanup/retention, fuller audits, real mirror atomicity and fault injection around database commits.

A lost or stale-restored database can invalidate delivery and receiver safety assumptions. The lease prevents overlapping claims on an intact shared database, but does not promise exactly-once delivery under all process pauses or distributed replicas. Receivers must remain idempotent. Revocation cannot retract transmitted bytes, and encrypted metadata hints never substitute for checking access during data retrieval.