Getting appointment data is sometimes really slow (especially itemId, subject, location, and optionalAttendees)

[pepso]

Your Environment

• Platform: PC Desktop
• Host: Outlook
• Office version number: New Outlook and Classic Outlook
• Operating System: Windows (11 & 10 / varied)

Expected behavior

We expect the appointment field data to be retrieved by Office.js library to be consistent, and returns faster than the 5 second limit before the Add-in's "Taking longer than expected" warning is shown. Because the add-in operates in the same runtime environment where the appointment is being created/edited the delays of up 60 seconds to retrieve the data are a bit confusing to us.

Current behavior

In about 0.8% of time sampled out of 30k appointment when we retrieve appointment's data fields during LaunchEvents it takes over 1 seconds to "getAsync" all the necessary fields. This is especially critical performance when in onAppoinmentSend event.

On New Outlook we see some cascading delays between the different appointment fields which could indicate the different fields are retrieved sequentially one API call per field we get from Office.js library.

On Classic Outlook any delay on fetching the appointment data usually is consistent between all the fields indicating the appointment is fetched as a whole and then given field at a time to the Office.js library / our Add-in.

Based on our telemetry data the performance of the optional attendees fetching is the worse offender taking up to a minute to return.

Here's the median, variance, and interquartile calculations of all API calls we use to get field data, and which take over 500 milliseconds to return.

Field	Variance	Median		Q1	Q3	IQ
itemId	18452747.58	976.00		570	2556	1986
start	18174814.81	827.00		598	1381	783
end	18237966.69	937.00		617.5	1769	1151.5
subject	18369962.34	942.50		569	2451.5	1882.5
location	18513042.41	942.50		570	2557.25	1987.25
optionalAttendees	39495846.14	939.00		579.25	2521	1941.75
requiredAttendees	23578782.59	848.50		570	2056.25	1486.25
organizer	23414073.40	782.00		570	1706	1136
recurrence	23635929.57	725.00		572	1616	1044
bodyHtml	23685735.92	726.50		561	1141	580
bodyText	23520033.47	694.00		560.5	991	430.5

The sampling is based on approximately 30k individual appointments where we get the field data.

We believe there is a bug or performance issue underlying the appointment field fetching which should be fixed. This seems to be compounded on New Outlook users because we see the cascading behavior on the field data fetching logic.

We have implemented a timeout to our implementation of "getAppointment" (fetches all the required fields), which we then fall back using custom logic for end user to not wait for a minute before they can send a simple appointment but this is then forgoes a lot of appointments.

Steps to reproduce

We have attempted everything available to us to replicate the issue consistently within our client site, and cloud hosted exchange servers without any luck. The telemetry data we gather however is pointing out to a real problem in the API data fetching in our client sites ~0.5% of the calls.

I'm happy to share our code to "getAppointment" which is just Promise'd way of fetching all fields in parallel. I however do assume you have a way better telemetry available to yourselves to understand the performance of the Office.js library's appointment data fetching.

We would love to have these 4 end points to perform faster and more consistent as they cause most of the issues in our client environments:

• Office.context.mailbox.item.getItemIdAsync
• Office.context.mailbox.item.subject.getAsync
• Office.context.mailbox.item.location.getAsync
• Office.context.mailbox.item.optionalAttendees.getAsync

Based on our investigation these delays happen on fast corporate networks, slow home networks, VPN environments, for simple appointments with few attendees, and up to big appointments with many attendees. Basically there's no consistent reason for the behavior we are able to point our finger towards.

Provide additional details

We cannot provide steps to reproduce as this is not something that looks to be our code related, but rather API performance related.

We are happy to share more information on how we see the issue and how we have verified the issue.

Context

The issue is present in client's environment and this generates distrust towards the add-in because we cannot validate all the appointments, but must skip some as the appointments not to show never ending "takes long" warnings.