Frequently receiving ErrorItemNotFound when calling 'me/message/[itemId]' on Outlook REST API

0
votes

We have an Outlook add-in that can be opened in ItemRead view.

This add-in sends requests to the Outlook REST API api/v2.0/me/messages/{message-id} endpoint to get further details on the currently viewed mail item.

We obtain the message ID for the request by calling convertToRestId on the office-js SDK with the itemId value of the current mail item.

We obtain the auth token for the request by calling getCallbackTokenAsync with isRest: true.

Despite the user currently being on the read item view for this item, we are getting a number of 404 responses from the REST API that the message is not found.

{
  error: {
    code: ErrorItemNotFound, 
    message: The specified object was not found in the store., The process failed to get the correct properties.
  }
}

I have been unable to reproduce this on any of my test accounts but this our most commonly reported issue in Sentry. It seems this can happen quite frequently

What could be the cause for this and is there any way to work around it?

I see a report of a similar issue here but there was not much response: ErrorItemNotFound error for message resource, but found when OData filter applied

1
outlookoffice-jsoutlook-restapi
On which platforms do you see this error (i.e. Windows/Mac/Web)? And about what % of messages are returning this error? – Outlook Add-ins Team - MSFT
@OutlookAdd-insTeam-MSFT it's difficult to assign a specific percentage to this but I see around 100 reports of it happening every week. I see this reported against OWA, Outlook for Windows and Outlook for Mac. I see it against both OutlookCom and Office365 account types. – David Fishlock
The behavior you are seeing can happen in some cases, like when the message is moved or the message is deleted. This is more likely to happen in Outlook for Windows since there's more of a delay in syncing data back to the server. – Outlook Add-ins Team - MSFT
@OutlookAdd-insTeam-MSFT it seems very unlikely that this explains the number of reports I am seeing of this. The user is actively looking at the email in the read item view when we make the request. We also see a number of reports of this against OWA where I don't think a sync delay explains this at all. – David Fishlock
@OutlookAdd-insTeam-MSFT any further response on this? It seems unlikely that we are seeing such a significant number of reports of this just from users who have moved an email immediately before opening the add-in. Especially on OWA it doesn't seem like this could really happen there. – David Fishlock

1 Answers

0
votes

For ErrorItemNotFound, we've investigated this error in the past, and it always correctly indicates that the item is not present on the server. There are a variety of ways this can happen, and some cases are transient while others are permanent.

Based on data collected earlier, I would expect about 1% or fewer GetItem requests to return ErrorItemNotFound. The error rate could vary across add-ins since the transient cases would depend on when the user interacts with the item.

When a user or service moves an item to another folder (i.e. archiving, deleting, or triaging an item), this causes the id of the item to change. An ItemNotFound error could be returned by an add-in running on a different client with an out-of-date view (even if the item appears on the user's screen, and they are able to run an add-in on it). Or, it could be returned by an add-in running on the same client if the move hasn't been synced to the server.

Clients with cached/offline data, like Win32 Outlook running in cached mode can experience transient ItemNotFound errors. If Outlook hasn't run in a while, or the user just configured their mailbox, Outlook could have a large number of items to sync, and this can delay syncing any changes to items or new items up to the server. If it's syncing other items, or temporarily disconnected from the server, it could allow the add-in to run before the item is available on the server. The item could be for a newly created item, or an item that was moved (i.e. archived/deleted/or otherwise triaged by the user).

Win32 Outlook has the ability (through MAPI) to return item ids that aren't available yet on the server. This is most noticeable when composing an email, but could also impact Read scenarios like in the following example.

I've personally seen this happen in Win32 Outlook after sending a message and opening it (in Read mode) from the Sent items folder (while Outlook was busy syncing items in other folders since I hadn't used that laptop in a few weeks). Outlook could have created the item there locally rather than downloading it from the server as you might expect.

If an add-in relies on data available both locally and from a server, it could provide reduced functionality, or show an error that the item can't be retrieved from the server.

If a service performs an asynchronous operation on an item from its backend, it could hold onto the request and try again later. But, since some portion of these errors are permanent, there's no guarantee that the request will succeed later.