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, synchronization profile and migration recovery rules.
Executable cases
Fourteen focused tests in 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.