driveItem delta returns an unchanged item (identical eTag, cTag and lastModifiedDateTime) across separate delta calls — is this expected?

We poll the driveItem delta API to watch a SharePoint document library folder and

raise an alert when its contents change. We are seeing repeated false alarms: items

are returned by delta when nothing about them appears to have changed.

Setup

• Graph v1.0, app-only auth (Sites.Selected)
• GET /drives/{driveId}/items/{itemId}/delta
• Polled once a minute; the deltaLink from each run is persisted and used as the cursor for the next run
• Each run is a separate delta call with its own fresh cursor — we are not paging through a single @odata.nextLink sequence

What we observe

An item is returned again several minutes after its last real change, with every

change-indicating field identical to the previous time we saw it:

| seen at | lastModifiedDateTime | eTag | cTag |

|---|---|---|---|

| T+0s | 10:55:10 | {GUID},260 | c:{GUID},257 |

| T+488s | 10:55:11 | {GUID},260 | c:{GUID},257 |

(The one-second difference is rounding in our own logging, not a difference in the

returned value.)

The second response carries no @removed facet and is a normal item entry.

For contrast, here is the same item while it was genuinely being edited. Both

counters advance on every poll, so the fields do track real changes reliably:

| seen at | lastModifiedDateTime | eTag | cTag |

|---|---|---|---|

| 10:52:19 | 10:51:59 | {GUID},255 | c:{GUID},252 |

| 10:53:19 | 10:53:13 | {GUID},257 | c:{GUID},254 |

| 10:54:19 | 10:54:17 | {GUID},259 | c:{GUID},256 |

| 10:55:22 | 10:55:10 | {GUID},260 | c:{GUID},257 |

This happened three times in about an hour, on different items in different folders.

In one case the gap between the original change and the repeat was roughly 12 minutes.

What we have already checked

The documentation notes that the same item may appear more than once in a delta

response and that the last occurrence should be used, and that ordering is not

guaranteed. Our repeats are not within one @odata.nextLink sequence, though —

they are in separate delta calls made minutes apart, each starting from the

deltaLink returned by the previous call.

Questions

1. Is an item expected to be returned again by a later delta call when its eTag, cTag and lastModifiedDateTime are all unchanged since the cursor was issued? Or does a returned item imply something changed that these fields do not expose (for example a permission or list-metadata change)?
2. If something did change, is there any field in the delta response that would let a client tell that apart from a content change?
3. Is comparing cTag against the last value a client has seen a supported way to decide whether a returned item's content actually changed?

Thank you!