perf(cloud): broadcast signals and storage-backed replay segments#511
Merged
Conversation
Pre-commit hook ran. Total eslint: 1, total circular: 0
Pre-commit hook ran. Total eslint: 1, total circular: 0
Pre-commit hook ran. Total eslint: 1, total circular: 0
Pre-commit hook ran. Total eslint: 1, total circular: 0
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Client side of ORGII-cloud-infra
0005_broadcast_and_storage_offload.sql— the two platform-level scalability directions the audit left open (H4 + H5). Both are capability-gated via the newget_cloud_capabilities()probe (missing RPC ⇒ legacy behavior, remembered per endpoint), so the client is fully backward compatible with pre-0005 backends and old clients keep working against a 0005 backend.H4 — change signals via Broadcast-from-Database. The client consumed zero row data from its postgres_changes subscriptions (pure invalidation edges), so signals now arrive as server-sent
org-db-changed {kind}broadcasts on the already-open private org channel. On broadcast-capable backends the two org-scoped postgres_changes channels are not created (channels per client drop 4 → 2), removing the per-change × per-subscriber RLS evaluation on the shared WAL poller — the platform's first scalability wall. Missed-signal recovery (disconnect-gated full/delta) moves to the org channel's SUBSCRIBED edge; the self-roster eviction slice deliberately stays on postgres_changes (a removed member is unreachable by join-time-auth broadcast).rosterbroadcasts also run the coarse recovery because the server's per-org debounce makes a member-floor change broadcast asroster(kind shadowing, documented in the migration).H5 — frozen replay segments offloaded to Supabase Storage. Frozen segments (
seq ≥ 1, immutable bulk) upload as raw gzip objects ({org}/{session}/{epoch}/{seq}-{hash}.gz, drops the base64 +33%) before the manifest RPC commits them; the server verifies object existence/size/hash-embedded-name againststorage.objects(server-measured quota, no client attestation). The mutable tail stays inline in Postgres, keeping append OCC single-transaction. Reads decodestoragePathXORpayloadGzper segment; client integrity validation (sha256 over pre-gzip bytes) is unchanged.Test plan
tscclean; Org2Cloud + TeamCollaboration slices 905/905 (26 new tests: capability probe caching, broadcast event dispatch + presence-channel status edges, storage PUT/GET wire shapes, storage-form append/rewrite, PGRST202 fallback + endpoint memory, ORG2_VALIDATION no-fallback, mixed inline/storage page decode, fail-closed cases); full suite green at branch point.