File attachments showing as message entities in Microsoft Graph API

Question

Recently we've noticed that the Microsoft Graph API has been returning file attachments as message entities returned from the /me/messages endpoint.

The scenario to reproduce is as follows:

• Send yourself an email (or have someone else send you an email) with one or more file attachments
• Run the following query in Graph Explorer: https://graph.microsoft.com/v1.0/me/messages
• Notice that there will be one object which represents the email itself (this is correct behaviour) and one or more objects which are representations of the file attachments.

It's also worth noting that these attachment "messages" have the same subject as the original email, the body content is set to the file content of the attachment (if the attachment is a document), there are no senders or recipients, they have an isRead status of true, and an isDraft status of true. Utter nonsense!

I can only assume this is a bug in the Graph API - I can't see any reason why this would happen by design. It's also worth noting that I've been working with the Graph API for around 9 months and this behaviour has only recently started happening.

Could someone from Microsoft please get in touch regarding this as soon as possible? This is a major bug in the API which will undoubtedly break most applications using it. It's also a great concern that a supposedly stable v1.0 is being changed underneath us. Why not use v1.1 or v2.0 for the next release?

Answer 1

thanks for reporting! I see this behavior as well if I retrieve messages via the /me/messages endpoint. If I retrieve via /me/mailfolders/inbox/messages, I do not. This is actually an important clue.

I looked at the parentFolderId of the messages. For the one that is "right", it was the ID of the Inbox. For the other, it was not. Whatever ID it is, I can't retrieve it via the API (I get a 404). So it's likely this is a hidden folder.

Playing with the IDs, I was able to convert to a MAPI ID and open it with MFCMapi. It turns out it's the Files folder. So I think the bug here is that /me/messages should not include the Files folder when returning results. I'll log a bug with our development team.