-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MalformedContinuationTokenException starting with SDK v3.7 #1364
Comments
Can you provide a reproduce for the error. If not we can start with a sample for how you are draining your query and passing the continuation token. As for the error message :
It looks like your continuation token is missing a field. It should be something like:
|
Thanks for the quick response. I took a look and the continuation token coming back from v3.6
v3.7
The query we are trying to run is a Because we want to get back exactly 100 results (no more, no less) to support paging the way we drain results is something we worked out together with you last summer if you may recall over Azure/azure-cosmos-dotnet-v2#692 when the SDK changed partition behavior from v2.2.2 to v2.2.3 Pseudo-real-code:
Thanks for your help! |
@codecadwallader quick question, is this happening when working with the Emulator (if so, which version?) or the live service? |
@ealsur The live service |
I wasn't able to reproduce this error. Can I get a console app that reproduces this issue? Thanks. |
Sure, I've been working on that. I'm also not able to reproduce it building up from a vanilla app so I'll need to spend some more time paring down our app and see what setting/aspect is making the difference. |
Ok, I've isolated the issue down to If you would still like a minimal reproducible solution I can provide it.. but it's probably easier for you to just feed this one line into your own test bed:
Thanks for your help! Addendum: This does not happen with every attempted query. It requires a query that will attempt to utilize the continuation token to get more results. |
@bchong95 Just sanity checking to see if you were notified of my second update re: NullValueHandling. If you'd still like the minimal reproducible solution I can provide it. |
@bchong95 any update on this? |
@bchong95. @j82w I have found the cause of this issue and a hacky workaround. So the reason this is happening is due to the code in FeedRangeCompositeContinuation. The issue is the classes use of JsonConvert from the Newtonsoft library. JsonConvert will use the default func handle for creating a serializer. So for instance if the consumer of the cosmos libs does something like...
Then the code in that class is going to attempt to deserialize\serialize the CompositeContinuationToken using ignore for the null value handling. The result is you will get a continuation token string without a token. then CompositeContinuationToken.TryCreateFromCosmosElement is going to end up throwing because the string no longer has a "token" value for any continuation token that returned a null token. If you have code that is trying to drain the feed then fetching more, i.e draining the feed in a while loop then using the continuation token to get more results it will end up potentially throwing out. I would like to make a suggestion that we utilize a static serializer in the FeedRangeCompositeContinuation class that ensures nulls are not ignored. EIther that, or making the TryCreateFromCosmosElement method skip the valiation checks for the properties. I am more than happy to make a PR if you guys think thats best or I can leave it to you guys. I know as a whole, Newtonsoft is being pulled out of the libs so maybe just using the System.Text.Json serializer is best. Here is my hacky workaround for anyone else that encounters this and needs a patch for the time being...
Thanks @codecadwallader for the tip. |
@vsadams This is great feedback, but query does not use FeedRangeCompositeContinuation. Query seems to go through https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/Query/v3Query/QueryIterator.cs#L80 |
Just to be sure, I also checked FeedRangeCompositeContinuation serialization/deserialization with your suggested global settings, with this test:
The serialization indeed does not have the
The issue seems to be with the mechanism used on queries to serializer/deserialize its continuation (which is not FeedRangeCompositeContinuation). |
@ealsur it is definitely possible that I am leading this astray. I have not pulled the source and debugged against it. I am purely going from reading the code in GitHub. However, the class FeedRangeCompositeContinuation does have a converter but CompositeContinuationToken does not. So when FeedRangeCompositeContinuation does something like Line 271 in 725931c
Again, very possible, I am wrong on this. I can pull code to double check but that was my inclination on why my work around worked. |
We agree on the behavior of FeedRangeCompositeContinuation, the string that gets output does not have the "token" property if you alter the global Json settings. But what I'm saying is that it doesn't affect when FeedRangeCompositveContinuation calls TryParse, it works as expected (the Token property is Now, going back to the original issue (the Malformed message), that is not related to FeedRangeCompositeContinuation, as queries do not use this class nor it is involved in the path that returns this error message. |
Gotcha, that makes sense! |
@ealsur I pulled the cosmos code and debugged it. Line 44 in f72a33d
In order to do a simple test to make sure this theory is correct, I removed my work around in my code base and tested it. I did get a malformed token originating there and eventually got the exception. I then modified the code and used a static serializer like
(Not pretty it was just a test)..but this worked. Hope this is helpful! |
@ealsur any update on whether or not this is getting in? |
@sboshra please share the update. |
We no longer use Newtonsoft to deserialize tokens, so any changes to the default serializer won't impact the query code in SDK: |
Describe the bug
We are seeing consistent MalformedContinuationTokenException exceptions starting with SDK v3.7 that did not occur with the same query in SDK v3.6. The same issue happens with SDK v3.8 as well.
To Reproduce
This is a cross-partition query over Gateway mode and as we continue to drain more results from the FeedIterator the exception will be thrown on a call to
await feed.ReadNextAsync()
. It looks like it may work for the first set of results from every physical partition then throws as it goes back to get a second set of results from a physical partition (my guess). Looking at Fiddler there is no error coming back over the wire, it appears to be purely inside the SDK.Expected behavior
The query to continue to return results as it did with SDK v3.6
Actual behavior
A MalformedContinuationTokenException is thrown with a reason "CompositeContinuationToken is missing field".
Environment summary
SDK Version: v3.7 and v3.8
OS Version: Windows
Additional context
Activity ID examples:
b0e3b405-f7e3-4c22-bf11-0a86fcd2782c
eed47b7d-f177-475b-849b-d0a5a67f4e77
Error message:
Call stack:
The text was updated successfully, but these errors were encountered: