Provider Implementations
Conformance expectations for custom storage, realtime, and file providers.
Provider contracts are narrow because correctness depends on their behavior.
Custom storage providers should be tested for:
- complete
ThreadVersioncompare-and-swap behavior and delete/recreate fencing; - scope-constrained reads and commits;
- opaque portable thread ids;
- version-consistent selective reads and stable opaque page tokens;
- atomic root, message, run, queue, and lease changes;
- provider-clock run/admin lease behavior;
- strict JSON validation and schema-versioned persisted records;
- expected conflict and unknown-commit behavior.
Custom realtime providers should be tested for:
- subscribe lifecycle;
- missed wakeup recovery;
- ordered enough frame delivery;
- duplicate/self-origin event tolerance;
- snapshot-on-reconnect behavior;
ThreadVersionfencing on lifecycle, generation, and ToolData events.
Realtime providers carry low-latency frame and wake signals. They do not own canonical state. A provider is correct if runtime instances can repair from snapshots after missed, duplicated, or stale signals.
Custom file providers should be tested for:
- save returning stable
fileIdvalues and metadata; - scoped file reads and URL creation;
- missing file behavior;
- content type and metadata preservation;
- stream cleanup;
- direct URL policy when supported.
Application developers usually do not need these tests unless they are implementing a custom provider.