Skip to content

Conversation

filipecabaco
Copy link
Member

@filipecabaco filipecabaco commented Oct 8, 2025

🔍 Description

Added new public method for explicit usage of REST API for broadcast

What changed?

New method httpSend added

Why was this change needed?

Our current approach leads users to use broadcast without knowing.

🔄 Breaking changes

  • New log warning to inform that users are using REST when using send while not connected.

📋 Checklist

  • I have read the Contributing Guidelines
  • My PR title follows the conventional commit format: <type>(<scope>): <description>
  • I have run npx nx format to ensure consistent code formatting
  • I have added tests for new functionality (if applicable)
  • I have updated documentation (if applicable)

@filipecabaco filipecabaco requested review from a team as code owners October 8, 2025 17:31
@coveralls
Copy link

Coverage Status

coverage: 95.455% (+13.0%) from 82.5%
when pulling 8eedcbd on fix/explicit-realtime-rest-call
into 00c4a11 on master.

grdsdev added a commit to supabase/supabase-swift that referenced this pull request Oct 8, 2025
This commit ports the feature from supabase-js PR #1749 which adds
an explicit `postSend()` method for sending broadcast messages via
REST API, addressing the issue where users may unknowingly use REST
fallback when WebSocket is not connected.

Changes:
- Add `postSend()` method to RealtimeChannelV2 for explicit REST delivery
- Add deprecation warning to `broadcast()` when falling back to REST
- Add comprehensive test coverage for the new method
- Support custom timeout parameter for REST requests
- Include proper error handling and status code validation

The `postSend()` method always uses the REST API endpoint regardless
of WebSocket connection state, making it clear to developers when
they are using REST vs WebSocket delivery.

Ref: supabase/supabase-js#1749

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
opts: { timeout?: number } = {}
): Promise<{ success: true } | { success: false; status: number; error: string }> {
if (!this.socket.accessTokenValue) {
return Promise.reject('Access token is required for postSend()')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the secret key is being used? Would we still need an access token?

@filipecabaco
Copy link
Member Author

#1751 as we need this to be a minor version change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants