Restart SSE connection in listenForItemChange() when not alive

[mueller-ma]

When restarting openHAB existing SSE connections may look like they are still intact to the client, but no further events are received. Thus restart a connection when no ALIVE events are received anymore.

[mueller-ma]

This raised ClosedReceiveChannelExceptions and crashes the app and I don't know why it isn't catched.

[maniac103]

'Raised' as in 'without the try-catch'? How exactly does the exception (message) look like?

[mueller-ma]

ACRA caught a ClosedReceiveChannelException for org.openhab.habdroid
kotlinx.coroutines.channels.ClosedReceiveChannelException: Channel was closed
	at kotlinx.coroutines.channels.BufferedChannel.getReceiveException(BufferedChannel.kt:1760)
	at kotlinx.coroutines.channels.BufferedChannel.resumeWaiterOnClosedChannel(BufferedChannel.kt:2202)
	at kotlinx.coroutines.channels.BufferedChannel.resumeReceiverOnClosedChannel(BufferedChannel.kt:2191)
	at kotlinx.coroutines.channels.BufferedChannel.cancelSuspendedReceiveRequests(BufferedChannel.kt:2184)
	at kotlinx.coroutines.channels.BufferedChannel.completeClose(BufferedChannel.kt:1961)
	at kotlinx.coroutines.channels.BufferedChannel.isClosed(BufferedChannel.kt:2240)
	at kotlinx.coroutines.channels.BufferedChannel.isClosedForSend0(BufferedChannel.kt:2215)
	at kotlinx.coroutines.channels.BufferedChannel.isClosedForSend(BufferedChannel.kt:2212)
	at kotlinx.coroutines.channels.BufferedChannel.completeCloseOrCancel(BufferedChannel.kt:1933)
	at kotlinx.coroutines.channels.BufferedChannel.closeOrCancelImpl(BufferedChannel.kt:1826)
	at kotlinx.coroutines.channels.BufferedChannel.close(BufferedChannel.kt:1785)
	at kotlinx.coroutines.channels.SendChannel$DefaultImpls.close$default(Channel.kt:95)
	at org.openhab.habdroid.util.HttpClient$SseSubscription.cancel(HttpClient.kt:307)
	at org.openhab.habdroid.util.ItemClient.listenForItemChange$restartSubscription(ItemClient.kt:126)
	at org.openhab.habdroid.util.ItemClient.access$listenForItemChange$restartSubscription(ItemClient.kt:36)
	at org.openhab.habdroid.util.ItemClient$listenForItemChange$resetAliveWatchdog$1.invokeSuspend(ItemClient.kt:141)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:231)
	at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:164)
	at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:466)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl(CancellableContinuationImpl.kt:500)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default(CancellableContinuationImpl.kt:489)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeUndispatched(CancellableContinuationImpl.kt:587)
	at kotlinx.coroutines.android.HandlerContext$scheduleResumeAfterDelay$$inlined$Runnable$1.run(Runnable.kt:15)
	at android.os.Handler.handleCallback(Handler.java:959)
	at android.os.Handler.dispatchMessage(Handler.java:100)
	at android.os.Looper.loopOnce(Looper.java:232)
	at android.os.Looper.loop(Looper.java:317)
	at android.app.ActivityThread.main(ActivityThread.java:8705)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:580)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:886)
	Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@9402587, Dispatchers.Main]

[mueller-ma]

You can test this by setting the delay in line 139 to less than 10 seconds.

[maniac103]

Thanks for the ping 😉 I totally forgot about this. My solution would be this patch.