Windows Classic Outlook Add-in requires setTimeout() to record custom APM transactions

Elastic Observability APM
1

Kibana version: 9.0.0

Elasticsearch version: 9.0.0

APM Server version: 9.0.0

APM Agent language and version: elastic/apm-rum-react@2.0.5

Browser version: Edge WebView2 (Chromium) (windows classic outlook)

Original install method (e.g. download page, yum, deb, from source, etc.) and version: N/A

Fresh install or upgraded from other version? Fresh

Is there anything special in your setup?
Yes, of course things are special as we are talking about an Outlook add-in running in classic desktop Outlook in windows (and other browsers/clients)!

In general we faced a lot of issues and worked around them in the end.
This add-in may open a Dialog which in Outlook is another iframe, we needed a custom transaction that could combine data from the initial app, the Dialog in one place lets say and each transaction to represent an email attempt linked to a validation (Dialog) transaction etc..

After we found ways to connect transactions via tracing, and output data the way we wanted the only issue we were facing was that we had to setTimeout() to the event.complete() function call (or to transaction.end() call..) for all transactions to be reliably recorded in kibana.

The solution there was the flushInterval: 0 in our config:

    apm = initApm({
        serviceName: 'service',
        serverUrl: "https://apm.host.io",
        serviceVersion: globalCfg.getVersion(),
        transactionSampleRate: 1.0,
        pageLoadTransactionName: isPortal ? 'Route: Validation modal' : 'Route: Send email',
        flushInterval: 0,
        environment: __DEV__ ? 'development' : APM_ENV,
    });

This made a big difference for all clients and transaction data were reliable with one small but crucial caveat.

In our main client of interest (windows classic) for only the quickest interaction
(no validation) the only way we can record it is to apply a timeout of at least 0.8 sec. Everything works fine in browsers and other desktop clients.

I know that this is most probably on the internal browser in Outlook or maybe how it handles pending requests etc, but would you have any piece of advice to avoid the timeout and make this work?

Questions to sum up

  1. Has anyone observed similar behavior in the Windows Classic Outlook host? :stuck_out_tongue:
  2. Is there a recommended way to force the RUM agent to complete and send its payload before returning from event.completed(), other than an arbitrary timeout?
  3. Agent internals: Does the JS or React wrapper expose a “flush and await” API we could call instead of transaction.end()?
  4. Alternative transports: Would switching to a custom transport (e.g. beacon, sendBeacon API) help here?

Performance is critical and adding an 800 ms delay in the send path is not an acceptable long-term solution. Any guidance or pointers would be greatly appreciated!

Thank you in advance!