PAIPAI

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 ThreadVersion compare-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;
  • ThreadVersion fencing 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 fileId values 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.