It is not recommended to
awaita long-running task inside an OTP behaviour such asGenServer. Instead, you should match on the message coming from a task inside yourGenServer.handle_info/2callback. For more information on the format of the message, see the documentation forasync/1.
In this case, the WS stores to DynamoDB, and publishes to Kafka. Those are fast operations in normal circumstances.
Could you folks help me understand what could happen in the Task.await/1 call in the original code?
The WS is not linked to the tasks because of the async_nolink call, but it still monitors them (the documentation of async_nolink does not say otherwise). Therefore, it receives exit signals from the task as messages. Channels have a handle_info callback, and it is not clear to me if Task.await/1 is correct in a Phoenix Channel at all because it enters a receive block to consume messages directly from the process mailbox. What do you think?
On the other hand, Task.await/1 emits exit signals from within that receive block, whose origin is the WS process itself. How is the supervisor of the WS going to react to those signals? Is this why it has been said in the thread that Task.await/1 would still need a rescue if I want the WS to not exit at all due to failures in those operations?
