ANR Monitoring in JavaScript

[AbhiPrasad]

getsentry/sentry-electron#729 raised the idea of doing Application Not Responding (ANR) detection in the Electron SDK. ANR's are a mobile concept typically (we also use the phrasing App Hangs for iOS), but are also valuable for desktop applications that need a smooth UX.

In JavaScript this is especially valuable as there is only one thread. The event loop hanging on the main thread effectively means no work can get done, which is a huge performance problem for browser, react native, electron, and server runtimes (node, bun).

We should figure out a way to automatically detect ANRs in JavaScript and report them to users. If we can, we should also attempt to attach a stacktrace or similar so users can figure out the source of the ANR and fix it directly.

Walking through our different platforms:

1. Electron Detect non-responsiveness (ANR) in Electron applications sentry-electron#729

For Electron renderer instances (the UI part of an Electron app), we can use Electron APIs to detect if they are unresponsive. Right now we actually have detection for this, but only generate breadcrumbs.

For the main thread, there is no approach. The main thread in Electron is just a node process, so it makes sense to first build a general solution for node and then apply that back to

2. Node

To get this working on Node, we can start a watchdog thread that will inspect the main thread to see if it has hanged. By leveraging the Inspector API, we can also generate stacktraces to pinpoint what is causing the hang.

4. Browser JavaScript

For browser JavaScript, we might want to explore a timeout based approach that ensures the event loop is not being stalled. This has overhead problems though since we are introducing event loop pressure ourselves with it.

In React Native we have stalltracking that is used to set app stall measurements. https://github.com/getsentry/sentry-react-native/blob/main/src/js/tracing/stalltracking.ts. Maybe we can use a similar approach that is more generic than just performance monitoring.

5. Other server runtimes

We can use watchdog threads in runtimes that support the necessary APIs, but stacktraces might not be possible because of no inspector API like in Node.

6. React Native

See Browser JS and https://github.com/getsentry/sentry-react-native/blob/main/src/js/tracing/stalltracking.ts.

Plan of Action

• Create experiment for Node ANR detection via watchdog threads @timfish
• Figure out generating and attaching stacktraces in Node ANRs @timfish
• Promote experiment to become Node integration (optional) @AbhiPrasad @timfish
• Use new ANR Node integration in Electron for main thread monitoring @timfish
• Decide if ANR detection needs to be in renderer processes also for Electron @timfish
• See if approach can be used in React Native @AbhiPrasad
• Investigate ANR detection in non-node runtimes @AbhiPrasad
• Investigate ANR detection in browsers @AbhiPrasad

[timfish]

I've created a Proof of Concept showing ANR detection as an integration for nodejs:
https://github.com/timfish/sentry-node-watchdog

This uses a worker thread which is periodically polled from the main thread.

It has two thresholds:

• warningThreshold is used to detect excessive event loop blocking. It continues to wait for the main thread to poll again so it can more accuratly estimate how long it was blocked for and this is then reported as a warning.
• hungThreshold is used as a maximum time to wait before we assume the main event loop is more permanently blocked and this is reported as an error.

I'm now working on attempting to get stack traces from the main thread from the worker.

Excessive event loop blocking in the Electron main process is an important metric since this can block communication between the GPU thread and renderer threads and cause jankiness.

[AbhiPrasad]

@krystofwoldrich if you have feedback about the React Native side of things would be great to get some insights!

[timfish]

My testing suggests that when the Debugger.pause command is sent, all threads, including worker threads are suspended. This means that unless I unearth something not-so-well documented, we're unlikely to be able to capture stack traces from worker threads.

It is possible to capture stack traces via a forked nodejs process with a couple of caveats:

• I'm not sure if they can be forked from inline code (ie. possible bundler issues)
• An extra process will have higher overhead

[timfish]

I've been working on a branch that captures ANR events from a forked child process:
https://github.com/timfish/sentry-node-watchdog/tree/child-process

The Watchdog integration starts a forked node process with the same entry point as the current process. To stop the background ANR process from running the main app code, we use a promise that only resolves in the main process:

import { init, anrWatchdog } from '@sentry/node';

init({ dsn: "__DSN__" });

// for esm with top-level await
await anrWatchdog({ captureStackTrace: true });
runApp();

// or for cjs
anrWatchdog({ captureStackTrace: true }).then(() => {
  runApp();
})

The background ANR process connects to the main process debugger interface via WebSockets and pauses when the event loop threshold is exceeded and captures a stacktrace:

[timfish]

Electron

One downside of using the debugging interface with Electron apps is that this opens debug ports for the main process and this probably has security implications for some apps

Renderer processes

The renderer unresponsive events are slow to be triggered and do not result in a stack trace. It might be possible to use the Electron debugger interface to get full stack traces however it might be tricky to detect ANR for renderers since Chromium can throttle renderers if they are in the background.

[krystofwoldrich]

For RN we want to explore the engine native APIs to attach stack trace when the JS loop is not responding.

At the moment we already use the Hermes engine APIs for profiling.