0

If I have a long running async method, which I call in my Mvc.Controller action method without awaiting it, is it guaranteed that it will finish even after I return from the action method?

Example:

[HttpPost]
public ActionResult DoLongRunningTask() {
    //not awaited async method
    LongRunningTask();

    return new HttpStatusCodeResult(HttpStatusCode.OK);
}

public async Task LongRunningTask() {
    await Task.Delay(5000);
}

Edit:

I did find How to safely call an async method in C# without await when googling about this, but I was wondering if someone could clarify regarding ASP.NET MVC specifically. When looking closer at all the answers in the question there are some information in this answer/links: https://stackoverflow.com/a/15523793/585968, as pointed out by @MickyD.

Unless someone has some more specific information specifically regarding ASP.NET MVC, I'll accept closing this question as a duplicate.

Community
  • 1
  • 1
Hein Andre Grønnestad
  • 6,885
  • 2
  • 31
  • 43
  • 2
    You should return status Accepted in this case rather than OK. Accepted means you have started but it hasn't been done yet and that processing might not complete. OK means you have already processed it successfully. – Greg Beech Feb 18 '16 at 07:52
  • 1
    Is your actual question closer to [How to run Background tasks in ASP.Net](http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx)? – Damien_The_Unbeliever Feb 18 '16 at 07:52
  • @GregBeech Fair point, this is just example code though. – Hein Andre Grønnestad Feb 18 '16 at 08:01
  • @Damien_The_Unbeliever Not really, cause I'm wondering how ASP.NET handles this case specifically. – Hein Andre Grønnestad Feb 18 '16 at 08:08
  • 1
    You should be able to *deduce* the answer from that blog post though. When it discusses QueueBackgroundWorkItem: "the ASP.NET runtime will try to delay AppDomain shutdown until these work items have finished executing. ... It can try to delay an AppDomain for as long as 90 seconds in order to allow your task to complete. If you can't finish in 90 seconds, then you'll need a different (and more robust, meaning, out of process) technique." – Damien_The_Unbeliever Feb 18 '16 at 08:11
  • @Damien_The_Unbeliever You're right. – Hein Andre Grønnestad Feb 18 '16 at 08:18

1 Answers1

0

Edit : No, it is not guaranteed (But almost)

Short answer: YES

Long answer: yes, but not always.

If async method takes more than your default timeout time it will be canceled. BUT if you’ve already sent your REST request (Or any remote hit and run API), it should not matter.

The way I resolved this problem is using Azure web jobs with queues. So My main application just sends request to “so something” and Azure just wait for each to complete before starting another one. While my WEB server is already go forward.

Edit : answering the question.

Jurion
  • 1,230
  • 11
  • 18
  • 1
    Answering _"yes, but not always"_ to a question of _"is it guaranteed"_ makes no sense. Regardless, not sure you are correct: _"[ASP.NET was not designed for this, and there's no guarantee that your code will run after the response is returned. ASP.NET will do its best to let it run, but it can't guarantee it.](http://stackoverflow.com/a/15523793/585968)"_ –  Feb 18 '16 at 07:54
  • It is not actually. The new task/thread will run to competition in most of the cases. There is a timeout to “cut off” (Still trying to find where to configure it). It seems be about 5 seconds by default. 5 seconds is MORE than enough for most of the tasks. That’s why I answered “Yes, but not always”. I’m using unwaited tasks to track some analytics on a site/app with a lot of visitors and to date never had a problem – Jurion Feb 18 '16 at 07:57
  • Good 'ol _"works on my machine"_ hey? –  Feb 18 '16 at 08:51