question

DanWahlin-6308 avatar image
0 Votes"
DanWahlin-6308 asked DanWahlin-6308 commented

Microsoft Graph me/messages returning incorrect @odata.nextLink $skip value

I'm working on some Microsoft Graph messaging code that targets .NET Core. It uses Me.Messages and skips through 5 messages at a time using $top and $skip. Everything works great until I get to the end of the messages and then I get a really strange issue with $skip.

After paging through the first few pages the $skip value jumps from 25 (there are records available with that value) to 191 (apparently when it's out of messages) rather than setting NextPageRequest to null or something along those lines (not passing back a @odata.nextLink value). The image below makes it more clear.

112287-skip-value-with-messaging.png


Any reason why the $skip value would jump from 25 to 191? If I set $skip to something like 30, 50, or 100 I just get the 5 records that $skip=25 would give me. If I set $skip=190 I get the last record shown when $skip=25 is set. I'm confused by it at this point. The code I'm using can be found here:

https://github.com/DanWahlin/DotnetCoreRazor-MicrosoftGraph/blob/main/Graph/GraphUtils.cs#L84

Something similar to this can also be emulated directly in Graph Explorer with the default account:

https://developer.microsoft.com/en-us/graph/graph-explorer?request=me%2Fmessages%3F%24select%3Dsubject%2CbodyPreview%2CreceivedDateTime%26%24top%3D5%26%24orderby%3DreceivedDateTime%26%24skip%3D0&method=GET&version=v1.0&GraphUrl=https://graph.microsoft.com

112239-skip-value-2.png

I'm not sure if I'm missing how this is supposed to work or if the API isn't returning correct values for @odata.nextLink $skip.


microsoft-graph-applications
· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Okay, I will try to reproduce your problem.

1 Vote 1 ·

I can't seem to reproduce your problem. I decoded your request url and tested it locally, and it returned the results I wanted perfectly.

0 Votes 0 ·

Thanks for taking a look. Did you run the Github project I provided above? That's the main concern.

Also, the link included for Graph Explorer has a skip value that jumps to 218 as shown in the screen shot which neither I nor others expected. Let me know specifically what you ran if you can.

0 Votes 0 ·

1 Answer

waldek avatar image
0 Votes"
waldek answered DanWahlin-6308 commented

This behavior is intentional. There are other elements stored in the mailbox that need to be skipped which is why the skip value isn't continuous. The recommendation is to use the value from the nextLink as-is and not construct skip links manually.

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks Waldek! I found out later about the noncontinuous values that you mention. However, there was another problem as well. For the benefit of others that may hit this, I'll provide some more details here. No skip links were manually being constructed actually. Everything was dynamically retrieved from NextPageLink that the SDK provides so even though $skip jumps around, the general process should have worked when combined with top.

var skipValue = pagedMessages
.NextPageRequest?
.QueryOptions?
.FirstOrDefault(
x => string.Equals("$skip", WebUtility.UrlDecode(x.Name), StringComparison.InvariantCultureIgnoreCase))?
.Value ?? "0";

It's true that the $skip link won't give a continuous value as you mentioned. However, the problem was also that at the time there wasn't a way to know when you were at the end of the records aside from checking if you got mail records back or not. NextPageRequest always had a value and $skip always had a non-zero value when I originally posted the question.

However, after updating to the latest assemblies, NextPageLink now gives a $skip value of 0 when at the end of the records. I would've expected NextPageLink to be null, but having a $skip=0 works fine too as long as it stays consistent. I don't know what changed (API or .NET Core SDK) but something definitely has been modified over the past few weeks. The good news is with $skip=0 I'm able to get past the original issue and allow people to move forward through emails.

2 Votes 2 ·