I have what I think is a fairly basic flow in an asychronous web api controller. The code looks like the following:
public async Task<IHttpActionResult> Put([FromBody] ObjectType myObject)
{
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
try
{
this.callbasicMethod();
myObject = await myRepository.UpdateDB(myObject);
await myRepository.DeleteSomeStuff(myObject.someProperty);
var table = Helper.CreateDataTable(myObject.anotherProperty);
await myRepository.InsertSomeStuff(table);
returnOk(myObject);
}
catch (Exception ex)
{
return BadRequest(ex.Message);
}
}
The problem is that none of the database calls (importantly the update call) ever execute. If I put a break point in this method around the update call, everything works just fine. It is like some sort of race condition is happening or something. Please let me know if you have an idea on how to fix this issue or what I am doing wrong.
Also, please let me know if you need any clarification, I had to obviously obfuscate the code to protect the intellectual property of the company I work for. If it helps any, the methods that are being called are implemented asynchronously themselves calling into asynchronous dapper methods to communicate with the database.
I finally found a work around, but not a true answer to why. Basically the two database calls that were being called were to delete some data from the table and then after that had been done add some data to the same table. I wrote one stored procedure to handle this and then one method within my data layer of my application and now everything is working.
Related
I have a controller where the functionality required is to implement a call where two actions are done simultaneously, first we get input and do a call to an external application then respond to the call OK we are working on it and release the caller. When the external application responds, we get the response and save to the db, I am using a task.delay as
Part 1
[HttpPost]
public async Task<IActionResults> ProcessTransaction(Transactions transactions)
{
// do some processing
TransactionResults results = new TransactionResults();
Notify(transactions, results);
return Ok("We are working on it, you will get a notification");
}
The delayed task
private void Notify(Transactions transactions, TransactionResults results)
{
Task.Delay(10000).ContinueWith(t => SendNotification(transactions, results));
}
on the SendNotification I am attempting to save the results
private void SendNotification(Transactions transactions, TransactionResults results)
{
// some processing
_context.Add(results); // this gives an error context has already been disposed
_context.SaveChanges();
}
Is there a better way to do this, or a way to re instantiate the context?
I managed to do a work around to the problem I am facing, I created an endpoint that I would call once the notification results came back and the data would be saved on the callback not at that particular event. Once the controller has respond with an Ok, the controller is disposed and its difficult to re instantiate it. The call back work around works for now, I will update if I find another way to do it.
I am trying to implement Google SSO in my C# web application. It seemed to be pretty straightforward. Based on this tutorial, Google does its magic in the web browser to get an Id_Token JWT. I pass the token is passed it to my web service for validation and use it to match it to a user in the application.
Although I am not sure if my approach with the server-side Google API is correct yet, my big hangup is trying to figure out how to work with the async call in the Google API to see what I get back.
My code is pretty simple using the Google.Apis.Auth namespace:
public async Task<GoogleJsonWebSignature.Payload> wfValidateAsync(string pId_Token)
{
GoogleJsonWebSignature.Payload Sig = await GoogleJsonWebSignature.ValidateAsync(pId_Token, null, false);
return Sig;
}
Although brand new to this async/await paradigm, I do have some experience in AngularJS / NodeJS promises / callbacks. My challenge is that it seems async methods can only be called by other async methods all the way back up the call-stack. I think it means ending the service call before the async response finishes and the service can act on the result.
Also, for creating unit tests, putting async into the [TestMethod] method makes it completely disappear from the test explorer. I'm not sure how to test/debug this conundrum.
Thanks in advance to anyone who can help me screw my head back on straight with this.
Although brand new to this async/await paradigm, I do have some experience in AngularJS / NodeJS promises / callbacks.
But not use Typescript, right?
My challenge is that it seems async methods can only be called by other async methods all the way back up the call-stack.
They should. Bad things can happen if you don't.
I think it means ending the service call before the async response finishes and the service can act on the result.
No! The compiler generates a state machine for methods with the async modifier and the await keyword means "go do something else and I'll come back here when I'm done".
Also, for creating unit tests, putting async into the [TestMethod] method makes it completely disappear from the test explorer. I'm not sure how to test/debug this conundrum.
You're probably making your test methods async void. They should be async Task in order for the test engine to know when the test is done.
Have a look at Stephen Cleary's blog. He has lots of content on async-await.
Paulo, Thank you!!
I was able to get this working with your advice on the last part about the test method. I had to change this:
//THIS TEST METHOD DOESN'T SHOW IN THE TEST EXPLORER
[TestMethod]
public async void AuthenticateGoogle()
{
string lToken = "[JWT TOKEN HERE]";
wfUser lUser = new wfUser(_wfContext);
var lAuthenticateResult = await lUser.wfAuthenticateGoogle(lToken);
Assert.IsTrue(lAuthenticateResult, "JWT Token Validated");
}
To this:
//THIS TEST METHOD SHOWS IN THE TEST EXPLORER
[TestMethod]
public async Task AuthenticateGoogle()
{
string lToken = "[JWT TOKEN HERE]";
wfUser lUser = new wfUser(_wfContext);
var lAuthenticateResult = await lUser.wfAuthenticateGoogle(lToken);
Assert.IsTrue(lAuthenticateResult, "JWT Token Validated");
}
NOW -- as an additional gotcha that was hanging me up, this will also cause a unit test to disappear from the test explorer, which I found out through lazy copy/pasting a non-test method's definition and mindlessly just adding a return when the build output told me I needed to return a value.
//THIS TEST METHOD DOESN'T SHOW IN THE TEST EXPLORER DUE TO RETURN VALUE
[TestMethod]
public async Task<bool> AuthenticateGoogle()
{
string lToken = "[JWT TOKEN HERE]";
wfUser lUser = new wfUser(_wfContext);
var lAuthenticateResult = await lUser.wfAuthenticateGoogle(lToken);
Assert.IsTrue(lAuthenticateResult, "JWT Token Validated");
return true;
}
In addition to the excellent blog you shared, this article from MSDN Magazine entitled Async Programming : Unit Testing Asynchronous Code helped me get my brain around it too.
What was hanging me up with all of this was mixing synchronous and async methods which, to your point, was not working well. The code seemed to skip the debug points I had set after the await calls as if it never ran them or, if it did run them, ran them somewhere I could not see and couldn't log to the debugger.
It was one of those terrible moments late on a Friday night where a developer starts to question both competence and sanity! :)
Thanks again for the help!
p.s. I incorrectly typed Angular JS in my question and meant Angular 4...and I am using TypeScript there. Some day I'll stop incorrectly referring the newer versions of Angular as AngularJS.
My challenge is that it seems async methods can only be called by other async methods all the way back up the call-stack.
It's not entirely true. You can use async method in sync methods. Of course you are losing most of the 'async' effect, but sometimes you have to. As async methods returs tasks you have some options.
When Task is returning result, any reference to t.Result will block execution till it's known. Another option is to use Task.Wait(preferably with timeout). For example code to validate google jwt token:
public bool ValidateGoogleToken(string token)
{
try
{
if(GoogleJsonWebSignature.ValidateAsync(token).Wait(1000))
return true; //success
//timeout exceeded
}
catch (Exception e)
{
//tampered token
}
return false;
}
I have inherited a web service that uses asynchronous calls for various things, but I have run into an issue that I can't rightfully explain.
I have (basically) the following workflow.
public CustomObject Work()
{
//synchronous work omitted
ContinueWithMethod1();
return retval;
}
public void ContinueWithMethod1()
{
ContinueWithMethod2().ContinueWith(x=>
{
if(x.IsFaulted) { //log error }
});
}
public Task<CustValue> ContinueWithMethod2()
{
<AzureDocumentDBLibrary>.UpsertDocumentAsync(value, value).ContinueWith(y =>
{
if(y.IsFaulted) throw y.Exception;
//populate CustValue
return retval;
}
);
}
The idea here is that the call to ContinueWithMethod1() inside of the Work() method is "fire and forget" so that execution passes to the return retval; statement immediately after calling ContinueWithMethod1(). If I put breakpoints on ContinueWithMethod1() and ContinueWithMethod2() the breakpoints are hit as I would expect and I don't see any errors generated in Visual Studio. The problem is that my call to Azure doesn't upload anything.
Some additional points:
If I execute this logic twice in a row the second call succeeds every time, but the first always fails.
If I change ContinueWithMethod1() to match the code sample below, everything works fine on the first pass through.
Code sample follows
public async void ContinueWithMethod1()
{
await ContinueWithMethod2();
}
The problem I think I have here is that depending on how long ContinueWithMethod2() my webrequest connection between the user and the server could time out.
Has anyone ever run into this problem with nested ContineWith() statements? If so can you explain what is going on and maybe how to debug the sequence of events that result in my first call to Azure being lost?
I am trying to load a document out of RavenDb via a WebAPI call. When I open an async IDocumentSession and call LoadAsync, I get no exception or result, and the thread exits instantly with no error code.
I was able to bypass all the structure of my API and reproduce the error.
Here is the code that will not work:
public IHttpActionResult GetMyObject(long id)
{
try
{
var session = RavenDbStoreHolderSingleton.Store.OpenAsyncSession();
var myObject= session.LoadAsync<MyObject>("MyObject/1").Result;
return Ok(myObject);
}
catch (Exception e)
{
return InternalServerError(e);
}
}
I simply hard coded the object's Id to 1 for testing, but calling the function for an object that doesn't exist (such as "MyObject/1") has the same result.
However, this code works:
public async Task<IHttpActionResult> GetMyObject(long id)
{
try
{
var session = RavenDbStoreHolderSingleton.Store.OpenAsyncSession();
var myObject= await session.LoadAsync<MyObject>("MyObject/1");
return Ok(myObject);
}
catch (Exception e)
{
return InternalServerError(e);
}
}
Things I tried/fiddled with:
Changing the exceptions that are caught in debugging
Carefully monitoring Raven Studio to see if I could find any problems (I didn't, but I'm not sure I was looking in the right places)
Running the API without the debugger attached to see if the error occurred or if something showed up in Raven Studio (no changes)
So I guess I have stumbled on a "fix", but can someone explain why one of these would fail in such an odd way while the other one would work perfectly fine?
In the real application, the API call did not have the async/await pair, but the code that was making the call was actually using async/await.
Here is the repository class that was failing which caused me to look into this issue:
public async Task<MyObject> Load(string id)
{
return await _session.LoadAsync<MyObject>(id);
}
The first part that is failing is as per design, for ASP.Net async call, you are blocking the Synchronization context, when you call the Result on a Task returned and same Synchronization context is required for call to return the data. Check out the following link by Stephen Cleary, where the same mechanism is explained in detail.
Second part works since that is correct way of using it and it's not getting into the deadlock anymore. First part can only work if you are using the Console application, which doesn't have a synchronization context to block, even other UI like winforms will have a similar issue and need to use the use the Second part of the code
I have a REST API with an Basic Filter. The Filter checks against the DB (mongodb) before the actual request is made, wether the user is authorized. however this only works for the first time, afterwards it always gets stuck at
var filter = Builders<User>.Filter.Eq("email", email);
return _collection.Find(filter).FirstOrDefaultAsync();
which basically looks up the user in the DB based on the Email. The task doesn't finish and neither does it throw a timeout exception .
My question is somewhat related to this : C# Mongo FirstOrDefaultAsync hangs
however their fix didn't do it for me. I can't just keep passing the async tasks up the call hierarchy because at some point the filter expects a sychronous action based on the results. and an await doesnt cut it either.
Any ideas? I can't be the 1st one building a REST API with Basic Auth and a MongoDB behind it...
Help would be appreciated:)
Update:
a call like this also results in problems:
//...
await fbUserRepo.UpdateAsync(user);
//the method
public async Task<Guid> UpdateAsync(TEntity entity) {
entity.lastUpdatedTimestamp = DateTime.Now;
var filter = Builders<TEntity>.Filter.Eq("_id", entity.Id);
await _collection.ReplaceOneAsync(filter, entity);
return entity.Id;
}
when this method is called, nothing happens, nothing is returned.. its just stuck later at a .Wait() ... I haven't changed anything on my configuration and it happens both locally as well as in the azure cloud. performing queries directly on the mongodb is no problem, there are also no currentOp() pending. Also no timeout is thrown. its just like my application decided not to do anything anymore. the thread just stays still
Update again
The odd part is: I can CRUD all sorts of stuff into the DB. Only when I come from my AuthenticationFilter is where I get this trouble. I crawled over a 100k documents from FB and dropped then into my DB, updated them, etc. But fetching and updating my User Documents through my BasicAuthFilter is giving me so much trouble. I just can't explain it... you might notice my frustration (2am now..)
.Result after the sync method will solve your problem.
like given below.
var filter = Builders<User>.Filter.Eq("email", email);
return _collection.Find(filter).FirstOrDefaultAsync().Result;
However make sure, the Method you're working on isn't marked "async" as an async method should not be blocking. More details here.
AFAIK, MongoDB only provides an asynchronous API, which IMO is a correct design decision.
I can't just keep passing the async tasks up the call hierarchy because at some point the filter expects a sychronous action based on the results.
If this is an ASP.NET WebAPI, you can make it async all the way, since WebAPI supports async filters just fine.
However, if your REST API is ASP.NET MVC, then you're in a hard place. The current version of MVC does not support async filters (or child actions). Note that ASP.NET vNext is merging WebAPI with MVC, and the new merged version does support async filters (and child actions). In the meantime, you'll have to do a hacky solution like replacing MyUserAuthenticationAsync().Wait() with Task.Run(() => MyUserAuthenticationAsync()).Wait(). (Note that MyUserAuthenticationAsync will run on a thread outside the HTTP request context).
Hacks like this should be minimized; they're only necessary in MVC filters and child actions. Regular controller actions should be made async and use await instead of Wait. And if this is WebAPI, then just use await in every scenario; don't use any hacks at all.