Fix panicking after starting UDP server due to closed "halt" channel #595
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates to: #594
Context
We use a oneshot channel between the main app that launches the UDP server and the running UDP server. It could be used to send the "halt" message to the UDP server. When the app starts the server this server waits for that signal.
That code is not working because when the server starts waiting the channel is closed. That does not affect the server that is still running. And currently, we are not using that signal in production (only for test environments).
Details
The "halt" channel is immediately closed after starting the UDP tracker. So the app panics with:
The UDP is started but it's not possible to shut it down gracefully.
I've added a lot of debug lines in this PR:
The function panicking is:
When the thread starts waiting for the signal it receives the error "channel closed".
I fixed a similar problem for the Tracker API and the HTTP Tracker:
Apparently the problem was the sender in the channel was dropped (I don't know why, it looks like a compiler optimization).
In the end, I think the problem was we were not waiting for the right spawned task. I've reorganized the code but the change that fixed the problem is:
We needed to wait for the launcher to finish because in this case, the launcher is not the thread that runs the final server. So we were only waiting until the launcher was "launched" but not for the final task running the UDP server. That is the reason why the channel was closed prematurely.
I have also normalized the log output:
I'm using targets for some reasons: