Electron tray app - reliably fetch in background after device suspended

[setchy]

Hi all!

I've been working on refactoring two existing tray/menubar Electron applications to use tanstack query.

These apps run mostly in the background / hidden state.

When configuring useQuery to refetchInterval and refetchIntervalInBackground, it will work for the most part, fetching new server data at the defined interval, even when the renderer is not visible.

That said, I've been having edge-case issues when waking devices that have hibernated for an extended period (ie: overnight). The background interval fetching seems to stop, only resuming after the first interaction with the tray/menubar app (note, i also have refetchOnReconnect and refetchOnWindowFocus set)

Any tips would be welcomed. For the time being, i've reverted to using an out-of-band interval polling function that calls refetch

[travisbreaks]

This is a well-known gap between how browser-based timer APIs work and how OS-level suspend/resume behaves, and it's especially sharp in Electron tray apps since there's no natural "window focus" event to bail you out.

Root Cause

refetchInterval under the hood uses setInterval (via TanStack Query's timeoutManager). When the OS suspends (sleep/hibernate), the JS event loop is frozen. On resume, setInterval callbacks don't retroactively fire for missed ticks. They just resume on their normal cadence, meaning your first refetch after an 8-hour sleep might not happen for another full interval cycle.

On top of that, refetchOnWindowFocus relies on visibilitychange events, and refetchOnReconnect relies on online/offline events. For a tray app that was never "hidden" or "offline" (the OS just froze everything), neither of those fires. The query observer checks focusManager.isFocused() before executing the interval fetch, and since document.visibilityState may not transition in a tray app, you can end up in a state where intervals just silently stop.

Solution 1: Electron powerMonitor + IPC (Recommended)

The most reliable approach. Electron's main process powerMonitor fires resume immediately when the OS wakes, regardless of renderer state.

Main process:

// main.ts
import { powerMonitor, BrowserWindow } from 'electron';

app.whenReady().then(() => {
  powerMonitor.on('resume', () => {
    // Send to all renderer windows
    BrowserWindow.getAllWindows().forEach((win) => {
      win.webContents.send('power:resume');
    });
  });
});

Renderer (preload or contextBridge):

// preload.ts
import { ipcRenderer, contextBridge } from 'electron';

contextBridge.exposeInMainWorld('electronPower', {
  onResume: (callback: () => void) => {
    ipcRenderer.on('power:resume', callback);
    return () => ipcRenderer.removeListener('power:resume', callback);
  },
});

React hook:

import { useEffect } from 'react';
import { useQueryClient } from '@tanstack/react-query';

export function useRefetchOnResume() {
  const queryClient = useQueryClient();

  useEffect(() => {
    const cleanup = window.electronPower?.onResume(() => {
      // Refetch all active queries immediately on wake
      queryClient.refetchQueries({ type: 'active' });
    });
    return cleanup;
  }, [queryClient]);
}

This is the cleanest solution because powerMonitor.resume is the OS-level truth. No heuristics, no drift detection.

Solution 2: Custom focusManager with Power Events

If you want TanStack Query's built-in refetch-on-focus machinery to handle this natively (so refetchOnWindowFocus: true "just works" after suspend), you can override the focusManager's event listener to include power resume as a focus signal:

import { focusManager } from '@tanstack/react-query';

focusManager.setEventListener((handleFocus) => {
  // Keep the default visibilitychange listener
  const onVisibilityChange = () => handleFocus();
  document.addEventListener('visibilitychange', onVisibilityChange);

  // Treat power resume as a focus event
  const cleanup = window.electronPower?.onResume(() => handleFocus());

  return () => {
    document.removeEventListener('visibilitychange', onVisibilityChange);
    cleanup?.();
  };
});

The focusManager.setEventListener API (from the source: it accepts a setup function that receives a setFocused callback and returns a cleanup function) is designed exactly for this kind of environment customization. Calling handleFocus() without a boolean argument triggers onFocus() directly, which notifies all observers and causes queries with refetchOnWindowFocus to refetch.

Same idea works for onlineManager.setEventListener if your device's network interface takes a moment to reconnect after wake.

Solution 3: Timer Drift Detection (No Electron APIs Required)

If you want something that works without wiring IPC (maybe useful during prototyping or in simpler setups):

export function useTimerDriftDetection(thresholdMs = 10_000) {
  const queryClient = useQueryClient();

  useEffect(() => {
    const interval = 5_000;
    let lastTick = Date.now();

    const id = setInterval(() => {
      const now = Date.now();
      const drift = now - lastTick;

      if (drift > interval + thresholdMs) {
        // Timer drifted significantly -- device was likely suspended
        console.log(`Detected suspend (drift: ${drift}ms), refetching...`);
        queryClient.refetchQueries({ type: 'active' });
      }

      lastTick = now;
    }, interval);

    return () => clearInterval(id);
  }, [queryClient, thresholdMs]);
}

This is a well-known pattern (Chrome DevTools uses a similar approach internally). The idea: if Date.now() - lastTick is significantly larger than your interval, the event loop was frozen. The downside is the refetch only triggers on the next tick after resume (up to interval ms delay), whereas powerMonitor.resume fires immediately.

---

For a tray/menubar app that's meant to be always-on, I'd go with Solution 1 since you already have the Electron main process available and powerMonitor is the authoritative signal. Solution 2 is a nice complement if you want the standard refetchOnWindowFocus option to cover this case transparently.

Out of curiosity, are your tray apps using BrowserWindow with show: false, or are you using something like menubar/Tray with a detached webContents? That might affect whether visibilitychange fires at all on macOS vs Windows, which could explain why refetchOnWindowFocus isn't catching even non-suspend cases.