Bug: ZeroConf pluging fails on App restart

Hi, I don’t know if this is the right forum to post this. Also, I tried to report a bug and I never got an ID to track it, so I wasn’t sure if the feature was working / I was reporting it properly.

Bug Description :

The ZeroConf plugin (link here) won’t work properly after restarting the app.

I thought the following bugs were independent but I realized that they have a common cause:

  • On Windows, the ZeroConf browser won’t call the previously initialized event listener after restarting the app (Ctrl+R), and no errors are displayed on the console.
  • On Android, the ZeroConf browser won’t call the event listener either (after restarting the app, i.e. when a file is changed and the app restarts automatically), and a subtle error is shown on the logcat:

“CoronaRuntimeTaskDispatcher.send() doesn’t have an available CoronaRuntime to run this task on! Abort!”
 

Steps to reproduce

The ZeroConf plugin fails when the app is restarted without closing.

  • In the Windows 10 simulator (simulating Android):

Launch the app, publish the service and start the browser… An event is issued.
Everything seems to work normally.
Stopping the browser and the service or not, does not affect reproducibility of the bug (it will happen anyway).
 
Now, press Ctrl+R to restart the app, publish the service again and start the browser… No event is issued this time.
The only solution is to close the simulator application, and start the simulator again.

  • Similarly, on an Android phone (using “logcat Corona:v *:s”)

Launch the app, publish the service and start the browser… An event is issued (again)
Everything seems to work normally.
Force a refresh on the phone through the Corona Live server (add and remove on space on the editor, and save the file)
Now, publish the service and start the browser… No event is issued.
However, the Android logcat shows:
“CoronaRuntimeTaskDispatcher.send() doesn’t have an available CoronaRuntime to run this task on! Abort!”

Comments
In my experience, this happens whether a single device or two devices are used for service/browser tasks.
Also, I am pretty sure that the logcat message is shown when the event is about to dispatch the event, but somehow, the dispatcher fails to be send the event, and that is probably why the event is never received on Android, and maybe, for a similar reason, also on Windows 10.

Code for testing purposes :

See attachment

What real use case do you need a restart?

You might want to rename the post.  I went looking for a zeroconfig plugin and couldn’t find one, only to realize you meant the ZeroConf plugin.

Also, it is always a good idea to include links even if you think the readers will know what you mean:

https://marketplace.coronalabs.com/corona-plugins/zeroconf

Given time, I’ll take a peek at this this weekend, but it may take a bit.  Meanwhile, the title change may help others engage w/ this more easily.

PS - Kudos and thanks for attaching an example to demonstrate the issue.  That is awesome. :slight_smile:

It caused me a few headaches during debugging, because I thought I was coding something wrong.

It took me a few hours to understand what it was happening, and I couldn’t find anything online about it (unlike the stopBrowse() bug, but that is a different topic)

I understand that this may not have an impact on the final user, but having to close/reopen the simulator every time is very impractical.

Even if nothing is done about it, at least it will be documented in the forums.

Thanks for catching my mistake roaminggamer, it should be corrected now.

I just want to mention that it is not the only plugin that fails this way. I forget exactly which but there are a few others that fail exactly as mentioned when you do live builds or when you do a restart from the adb command. Basically the connections stays open and there is no way for it to timeout before you request the next connection. The plugins don’t close the connection before restarting.

The problem happens even if I manually close the connection.

It is not that I forget to do it. it happens either way.

@asensio,

Hi.  I haven’t been able to debug this yet and I’m running out of time, so I hope someone else here has more time and can give you assistance.  Apologies, but I only have a small amount of free time weekly anymore.  This week’s free time has mostly gone to home maintenance. :frowning:

That is okay. At least, now, it is documented.

If someone would like to dig deeper on this bug, I can help you.

Thanks

What real use case do you need a restart?

You might want to rename the post.  I went looking for a zeroconfig plugin and couldn’t find one, only to realize you meant the ZeroConf plugin.

Also, it is always a good idea to include links even if you think the readers will know what you mean:

https://marketplace.coronalabs.com/corona-plugins/zeroconf

Given time, I’ll take a peek at this this weekend, but it may take a bit.  Meanwhile, the title change may help others engage w/ this more easily.

PS - Kudos and thanks for attaching an example to demonstrate the issue.  That is awesome. :slight_smile:

It caused me a few headaches during debugging, because I thought I was coding something wrong.

It took me a few hours to understand what it was happening, and I couldn’t find anything online about it (unlike the stopBrowse() bug, but that is a different topic)

I understand that this may not have an impact on the final user, but having to close/reopen the simulator every time is very impractical.

Even if nothing is done about it, at least it will be documented in the forums.

Thanks for catching my mistake roaminggamer, it should be corrected now.

I just want to mention that it is not the only plugin that fails this way. I forget exactly which but there are a few others that fail exactly as mentioned when you do live builds or when you do a restart from the adb command. Basically the connections stays open and there is no way for it to timeout before you request the next connection. The plugins don’t close the connection before restarting.

The problem happens even if I manually close the connection.

It is not that I forget to do it. it happens either way.

@asensio,

Hi.  I haven’t been able to debug this yet and I’m running out of time, so I hope someone else here has more time and can give you assistance.  Apologies, but I only have a small amount of free time weekly anymore.  This week’s free time has mostly gone to home maintenance. :frowning:

That is okay. At least, now, it is documented.

If someone would like to dig deeper on this bug, I can help you.

Thanks