feat(realtime): add postgres_changes_wait capability - #106
Conversation
Registers the wait-for-server-confirmation option on postgres_changes subscriptions (see supabase-js#2630) so SDKs can declare compliance against a stable feature ID.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughSummary by CodeRabbit
WalkthroughThe change adds the Merge Risk: ⚪ Minimal · up to This localized change documents and registers the PostgreSQL changes confirmation-wait capability without introducing an actionable merge-blocking risk; it is merge-ready after normal checks and review. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
||
| ## Prerequisites | ||
|
|
||
| Only meaningful on a channel with a `postgres_changes` binding; has no effect on channels without one. Requires a Realtime server version that sends the subscription-active confirmation message. |
There was a problem hiding this comment.
Perhaps including that server version here might be useful.
|
|
||
| - Without `wait: true`, a successful subscription is reported on channel join regardless of postgres_changes streaming state — the existing default behavior is unchanged for callers who don't opt in. | ||
|
|
||
| ## Related |
There was a problem hiding this comment.
In the GitHub renderer these links don't work... is there tooling downstream that comprehends them? They're nominally relative in nature but when that's interpreted for this markdown document then they're clearly invalid. 😕
| - subscription not confirmed — the server responds with `wait` enabled but the subscription cannot be confirmed active (e.g. replication setup failure); the subscribe outcome carries the server's reason instead of a false success | ||
| - timeout — the server does not confirm within `postgres_changes_options.timeout` milliseconds | ||
|
|
||
| ## Notes |
There was a problem hiding this comment.
I've mentioned it in a couple of places before, but can quiet down on this if you prefer, but I'm not so sure 'Notes' on a document that itself is 'Notes'-in-nature, is a great sign of clarity. 🤔
A dedicated Notes section is redundant on a document that is already free-form notes — fold platform/behavior asides into Behavior or Prerequisites instead. Updates the template, the capability-matrix skill's guidance, and the postgres_changes_wait spec. Addresses review feedback on #106.
2 participants
Summary
realtime.subscriptions.postgres_changes_wait— the wait-for-server-confirmation option onpostgres_changessubscriptions (postgres_changes_options.wait/.timeout), added to supabase-js in supabase-js#2630.specs/realtime/subscriptions/postgres_changes_wait.mddescribing the behavior, prerequisites, and error/timeout conditions in SDK-neutral terms.Test plan
npm run validate— OK, capability matrix is validnpm test— 195 passednpm run typecheck— cleanRefs SDK-1650