When building modern applications, there are often situations where you want to perform tasks in the background without holding up the main flow of your application. This is where “fire-and-forget” m...
Updated Nov 23, 2024
Version 1.0
Blog Post
Hi Syed,
if I were to review this in a pull request, I would strongly encourage you to refactor this.
Frankly, to call this code a "best practice" is dangerous advice to anyone seeking out knowledge in the realm of async programming in C#. Let me explain to you why I think that way:
Sending off the async method `SendUserCreationMail` in a Task.Run and then not awaiting the corresponding task is as bad as having an `async void` signature in your code base and pretending your code would be async.
The reason for this is that any exception happening inside of that method is lost in the CLR's nirvana and will never be caught by the outside try-catch because the task is not awaited. This is dangerous and can be the root cause for numerous bugs:
- The consuming code will not know that there ever was an error. This code might work 99% of the time. The remaining 1% will be users complaining about emails that were not received and you were not even aware of this.
- There is no chance of knowing that something was off from outside of SendUserCreationEmail, because nothing is logged. If you are lucky, it will pop up as an UnhandledTaskException, but the stacktrace information is still lost.
- There is no chance of retrying to send the email, because of the above reasons.
That being said, your ultimate goal is to do something (potentially long-running) without affecting the primary business process (add-user). There are many ways to do this properly:
- Using an IHostedService and a simple mechanism to schedule work on a background thread (e.g., channels, queues, etc.)
- Using a proper messaging solution (MassTransit, NServiceBus) on top of a message bus. Even in-memory would be a good fit, giving you the chance to configure retries for the actual sending out-of-the-box.
TLDR, using an observed Task.Run is nothing more than a workaround and I would not encourage anyone to use this in a production environment.
Cheers,
Dennis
Hello Dennis,
Thank you for taking the time to provide such a detailed and thoughtful review. I really appreciate your feedback, as it brings up critical points that anyone delving into async programming should understand.
You are absolutely correct in pointing out the dangers of using Task.Run in a fire-and-forget scenario without proper error handling. Exceptions going unobserved can indeed result in subtle and difficult-to-debug issues, especially in critical operations like email notifications.
However, I’d like to clarify the intent of my blog post. The goal was to discuss the specific use case of fire-and-forget patterns for tasks that are non-critical, where introducing a full-blown background processing system or a messaging solution might be overkill. I emphasized the importance of using fire-and-forget correctly in such scenarios, not as a replacement for robust background task handling in critical workflows.
Regards,
Syed Shahriyar