dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
34.9k stars 9.86k forks source link

Nullpointer exception in SignalR Java SDK 8.0.0 HubConnection class #52907

Open minkiapps opened 7 months ago

minkiapps commented 7 months ago

Is there an existing issue for this?

Describe the bug

After updating the SignalR SDK to 8.0.0 in our Android app, we are receiving app crashes in Google Firebase Crashlytics.

Fatal Exception: java.lang.NullPointerException: Attempt to invoke interface method 'rf.a com.microsoft.signalr.Transport.stop()' on a null object reference
       at com.microsoft.signalr.HubConnection.lambda$stop$16(HubConnection.java:448)
       at io.reactivex.rxjava3.internal.observers.CallbackCompletableObserver.onComplete(CallbackCompletableObserver.java:53)
       at io.reactivex.rxjava3.internal.operators.completable.CompletableOnErrorComplete$OnError.onError(CompletableOnErrorComplete.java:64)
       at io.reactivex.rxjava3.subjects.CompletableSubject.onError(CompletableSubject.java:126)
       at com.microsoft.signalr.HubConnection.lambda$start$12(HubConnection.java:358)
       at io.reactivex.rxjava3.internal.observers.CallbackCompletableObserver.onError(CallbackCompletableObserver.java:64)
       at io.reactivex.rxjava3.internal.operators.single.SingleFlatMapCompletable$FlatMapCompletableObserver.onError(SingleFlatMapCompletable.java:97)
       at io.reactivex.rxjava3.internal.observers.ResumeSingleObserver.onError(ResumeSingleObserver.java:51)
       at io.reactivex.rxjava3.internal.operators.single.SingleFlatMap$SingleFlatMapCallback.onError(SingleFlatMap.java:91)
       at io.reactivex.rxjava3.internal.operators.single.SingleMap$MapSingleObserver.onError(SingleMap.java:70)
       at io.reactivex.rxjava3.subjects.SingleSubject.onError(SingleSubject.java:153)
       at com.microsoft.signalr.DefaultHttpClient$2.onFailure(DefaultHttpClient.java:149)
       at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:525)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
       at java.lang.Thread.run(Thread.java:1012)

Expected Behavior

Check for null before accessing the class to avoid null pointer exception.

Steps To Reproduce

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val hubConnection: HubConnection = HubConnectionBuilder
            .create("https://someInvalidUrl")
            .build()

        hubConnection.start()
            .subscribe({
                Log.d("SomeTag", "Successfully connected to Webserver")
            }, { e ->
                Log.e("SomeTag", "Failed to start connection: ${e.message}")
            })

        hubConnection.stop()  // <------ this leads to app crash
            .subscribe({ 
                Log.d("SomeTag", "HubConnection Stop Success")
            }, {
                Log.e("SomeTag", "HubConnection Stop Failed: ${it.message}")
            })
    }
}

Exceptions (if any)

No response

.NET Version

No response

Anything else?

Android code example is attached: SignalRBugForGithub.zip

bunjix commented 6 months ago

Got the same issue for high number of users in production

pdapnz commented 3 months ago

We also encountered this problem. This situation occurs not only in the case of an incorrect URL. Also, these failures are observed when the Internet is slow and unstable, and when the network is switched from GSM to Wifi.

In version 7.x, the try catch block helped, but in version 8.x the application crashes, even despite the exception being processed.

        try {
            mHubConnection.stop().blockingAwait();
        } catch (Exception e) {
            Timber.e(e);
            mCrashLogger.logException(e);
        }

Are there any ideas what this might be related to? Could RxJava's application-side exception handling be inconsistent? On the server side, we could not detect such failures in the logs.