microsoftgraph / microsoftgraph/msgraph-sdk-dotnet
MailItem Message ID Changes After Sending — Causes ‘Item Not Found’ on Lookup
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 789
- Forks
- 264
- Avg merge
- 15h 17m
- Merged PRs (30d)
- 3
Description
Describe the bug
We are using Microsoft Graph to create and send emails in the following way:
- Create a draft message
var draftMessage = await graphClient.Users[userEmail].Messages.PostAsync(message); - Send the draft message
await graphClient.Users[userEmail].Messages[draftMessage.Id].Send.PostAsync(); - Get the sent message using its internetMessageId
After sending, we try to retrieve the sent message by filtering with its internetMessageId:
var filter = $"internetMessageId eq '{draftMessage.InternetMessageId}'";
var messageCollectionResponse = await graphClient.Users[userEmail].Messages.GetAsync(
requestConfiguration => requestConfiguration.QueryParameters.Filter = filter
);
The issue is
When we create the draft, we receive an initial message.Id.
After sending the message, we can look it up successfully using the internetMessageId.
However, after some time, the original messageId becomes invalid — it changes in the mailbox, and trying to retrieve the message by the old ID results in an ErrorItemNotFound error.
Expected behavior
The messageId returned when creating or sending the message should remain consistent and valid
How to reproduce
.
SDK Version
5.16.0
Latest version known to work for scenario above?
No response
Known Workarounds
No response
Debug output
Click to expand log
```</details>
### Configuration
_No response_
### Other information
_No response_
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the create-draft, send, and internetMessageId lookup calls shown in the issue, then reproduce the delayed lookup failure against Microsoft Graph. Compare the returned message IDs before and after sending and determine whether the behavior is in the SDK or the service; done means documenting the cause and an actionable resolution or workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100