Intermittent ErrorItemNotFound on message/attachment GET after change notifications (async)

Describe the bug

We use Microsoft Graph to read Outlook messages and attachments in an async integration (processing runs after Microsoft Graph change notifications, e.g. AWS Lambda / SQS).

We resolve the message and attachments roughly like this:

// After we receive a notification with a resource id, we fetch the message:
var message = await graphClient.Users[userEmail].Messages[messageId].GetAsync();

// We list attachments, then fetch a specific attachment:
var attachments = await graphClient.Users[userEmail].Messages[messageId].Attachments.GetAsync();
var attachment = await graphClient.Users[userEmail].Messages[messageId].Attachments[attachmentId].GetAsync();

Equivalent REST calls:

GET /v1.0/users/{id}/messages/{message-id}
GET /v1.0/users/{id}/messages/{message-id}/attachments/{attachment-id}

The issue is

We obtain messageId (and attachmentId when listing attachments) from Graph during processing.
Intermittently, a later GET returns ErrorItemNotFound for that same id.
The same request may succeed in Graph Explorer or on retry after a delay, which does not match stable “store this id forever” behavior for async jobs.

Additionally: a customer may copy an attachment id from Graph Explorer, but CloudWatch logs for our pipeline often show a different attachment id (or no attachment id) for the same message — messageId may align, attachmentId may not — so we cannot reconcile Explorer vs our logs.

Expected behavior

messageId and attachmentId returned by Graph should remain valid for GET for long enough or Microsoft should document when ids can change and what async integrators must persist instead (e.g. refetch, internetMessageId, or other supported pattern).

How to reproduce

Intermittent.

References (optional)
Stack Overflow: MS Graph message API attachment id changed
Stack Overflow: Item ids and attachment ids that change

SDK Version
Microsoft.Graph: 5.5.6/5.5.7

Start with the Microsoft.Graph 5.5.6/5.5.7 calls shown in the issue and compare the message and attachment GET requests with the equivalent REST requests. Investigate the intermittent ErrorItemNotFound behavior after change notifications, including retries and the differing attachment IDs; the issue provides no repository file or test to target, so done would require a documented, reproducible SDK or service-level explanation.