Description
What is the issue?
Currently ChannelAuthorizer
expects a synchronous authorize
implementation that returns a string.
It would be nice to rewrite it in a more asynchronous way, so that ChannelAuthorizer
interface wouldn't force the implementation to block the thread if authorize
requires async job.
It limits Kotlin usage e.g. in your React Native SDK, that needs async job by design (of React Native bridge):
Native Java/Kotlin module sends an event to Javascript and later Javascript calls Native module with auth object.
Related issue in your React Native SDK: pusher/pusher-websocket-react-native#37
Is it a crash report? Submit stack traces or anything that you think would help
Nope, but please check the linked issues for more context and possible freezes/errors.
Any improvements you suggest
The React Native SDK (Android/Kotlin code) uses mutex to block the thread and wait until JavaScript returns proper auth object through RN bridge.
It's not really a common flow in RN world (to block the thread in RN module), because it can lead to various issues/freezes/crashes/leaks.
Instead, it is preferred to implement logic in an asynchronous way (listeners/storing callbacks) since RN bridge is also asynchronous.
There was a similar but more serious issue in iOS part of your React Native SDK:
pusher/pusher-websocket-react-native#34
But it can be fixed by simply storing callbacks instead of blocking the thread:
pusher/pusher-websocket-react-native#36
However, it is not possible to implement it like this in Android (Kotlin) part, because of the ChannelAuthorizer
interface.
So my suggestion would be to rewrite ChannelAuthorizer
in a way that supports async/delayed response.
For example (there might be a better way, but this should do the job):
// old
String authorize(String channelName, String socketId)
// new
void authorize(String channelName, String socketId, Callable<String> authResultCallback)
I know it would be a breaking change, but it should be possible to add backwards compatible util (that simply calls authResultCallback
instead of return
) or support both ways.
CC @pusher/mobile