Task.Supervisor.async/2 task lifecycle after Task.await/2 timeout

Resolution

The caller should invoke Task.shutdown/1 directly after receiving a :timeout result from Task.await/2. Because Task.Supervisor.async/2 decouples the task from the caller to prevent cascading failures, the BEAM will not automatically terminate the task when the caller stops waiting.

Implementation Pattern

To ensure the background process is reaped, wrap the await call in a case statement that handles the timeout explicitly:

task = Task.Supervisor.async(MySupervisor, fn -> 
  # Long running work
end)

case Task.await(task, 5000) do
  :timeout ->
    Task.shutdown(task)
    {:error, :timeout}
  result ->
    {:ok, result}
end

Technical Explanation

The behavior is a result of how Task.Supervisor manages process links. In a standard Task.async/1 call, the task is linked to the caller; if the caller dies, the task dies. However, Task.Supervisor.async/2 links the task to the Supervisor, not the caller. This ensures that if the caller crashes, the task can still complete its work or be managed by the supervisor's strategy.

Task.await/2 is a blocking call that monitors the task's mailbox. When the timeout elapses, it simply returns :timeout to the caller. It does not send a signal to the task process. Without an explicit Task.shutdown/1, the task will continue to consume resources until it either completes naturally or the Supervisor itself is terminated.

Impact on Cleanup Code

• Exit Signals: Task.shutdown/1 sends an exit signal to the process. If the task is using try...after blocks or trapping exits, these cleanup mechanisms will be triggered.
• Safe Termination: Calling Task.shutdown/1 on a task that has already finished is safe and will not raise an error.
• Non-Interruptible I/O: Be aware that if the task is stuck in a non-interruptible C-node or certain binary operations, the shutdown signal may be delayed.

Verification

You can verify this behavior in an IEx session by starting a task with a long Process.sleep/1, awaiting it with a short timeout, and checking the process status:

# Check if process still exists after timeout
:erlang.process_info(task_pid)

# After Task.shutdown(task_pid)
:erlang.process_info(task_pid) # Should return :undefined

Diagnostic Detail: Are you using Process.flag(:trap_exit, true) inside the async task? If so, Task.shutdown/1 will send a message rather than killing the process immediately, requiring the task to handle the exit message to terminate.