Getting appointment data is sometimes really slow (especially itemId, subject, location, and optionalAttendees) #4917
Labels
Area: Outlook
Issue related to Outlook add-ins
Needs: attention 👋
Waiting on Microsoft to provide feedback
Your Environment
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.
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:
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.
The text was updated successfully, but these errors were encountered: