calendarView/delta can loop forever with changing @odata.nextLink values but repeated identical page payloads

Describe the bug

We are seeing an infinite pagination loop on calendarView/delta for a recurrence-heavy mailbox.

The failure mode is:

• the first pages look normal
• a later page returns @odata.nextLink
• following that @odata.nextLink returns the same page payload again
• each repeated response contains a different @odata.nextLink
• no @odata.deltaLink is ever returned
• this can continue indefinitely unless the client detects the loop and aborts

This is not a normal delta replay case where some entities reappear across pages. In our case, the full page payload repeats unchanged except for the @odata.nextLink value.

Endpoint

GET /v1.0/users/{mailbox}/calendarView/delta?startDateTime=...&endDateTime=...

We are using application permissions.

Impact

This blocks synchronization for the affected mailbox entirely.

Our worker would otherwise loop forever on the same delta session, so we had to add a guard that aborts when identical page payloads repeat across changing @odata.nextLink values.

Observed behavior

For one affected mailbox, we saw:

• page 1..N begin normally
• later pages start repeating the same event-id set
• @odata.nextLink changes on every response
• the event payload does not materially change
• no terminal @odata.deltaLink is returned

Example of our detection logic:

• page fingerprint is derived from the ordered event IDs in value
• repeated fingerprint observed on consecutive pages
• nextLink digest changes, but payload fingerprint stays the same

Sanitized example from production logs:

• repeated page fingerprint: 204fb4a75e1f
• repeats detected: 4
• current page when aborted: 5
• total items accumulated before abort: 1348

Expected behavior

One of the following should happen:

• @odata.nextLink should advance to a new page with new items, eventually ending in @odata.deltaLink, or
• the service should return a proper error response if the delta session cannot progress

It should not return an endless sequence of different @odata.nextLink values for the same page payload.

Reproduction pattern

We cannot share the affected tenant or mailbox, but the issue appears to correlate with:

• calendarView/delta
• a wide date range
• recurring events / recurrence-heavy calendars

In our environment, the request range is large enough to include future recurring instances.

We have also seen that changing Prefer: odata.maxpagesize=... can sometimes change whether the loop occurs, but not reliably. Smaller page sizes help in some cases and fail in others.

Request details

Sanitized request shape:

GET https://graph.microsoft.com/v1.0/users/{mailbox}/calendarView/delta?startDateTime={start}&endDateTime={end}
Authorization: Bearer {token}
Prefer: odata.maxpagesize=100
client-request-id: {guid}

Follow-up requests use the full opaque @odata.nextLink URL exactly as returned.

We do not parse or modify the skip token.

What we already verified

• We treat @odata.nextLink and @odata.deltaLink as opaque and replay the exact returned URL.
• We do not append extra query params after the initial request.
• We have independent detection for:
  • repeated identical nextLink
  • repeated identical page payloads across changing nextLink
• This is not just a duplicate entity appearing later in delta. It is the entire page repeating.
• We found other public reports that appear to describe the same issue:
  • Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/5790953/graph-api-calendar-events-delta-query-infinite-loo
  • This GitHub issue: https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/3070

Current workaround

Our current workaround is:

• detect repeated page payloads
• abort the delta session
• retry with a different odata.maxpagesize
• if that still fails, fall back to a full resync path on our side

This avoids an infinite loop, but it is only a mitigation and does not solve the underlying service behavior.

Questions

1. Is this a known Microsoft Graph service issue for calendarView/delta?
2. Is there a recommended server-supported workaround beyond changing odata.maxpagesize?
3. Are there known constraints around recurrence expansion and wide calendarView windows that should be documented?
4. Is there any additional request metadata Microsoft would like us to capture for escalation, beyond client-request-id, timestamp, and full nextLink sequence?

Additional notes

We can provide, through a support channel if needed:

• exact timestamps
• sanitized sequences of nextLink digests
• sanitized page fingerprints
• client-request-id values
• correlation data from the failing session

We are intentionally omitting tenant IDs, mailbox addresses, access tokens, event subjects, and other customer-identifying data from this public report.

Start with the calendarView/delta endpoint and the documented Microsoft Graph delta-query behavior. Reproduce the recurrence-heavy, wide-window request if possible, recording the full nextLink sequence and page fingerprints; the issue is done only when the service behavior is confirmed, documented, or routed with actionable escalation data.