Summary

Fixes #10543

broadcastQueryClient silently causes unhandled DataCloneError rejections when a query's state.data contains non-cloneable values like ReadableStream, Response, File, or framework proxies. These rejections surface in error trackers (Sentry/Datadog) with stacks pointing into node_modules, making them impossible to trace to specific queries.

Root Cause

In packages/query-broadcast-client-experimental/src/index.ts, the three channel.postMessage() calls (lines 40, 49, 57 — for updated, removed, added events) do not have .catch() handlers. When the structured-clone algorithm encounters non-cloneable data, broadcast-channel rejects internally, producing an unhandledrejection event.

Fix

Added .catch(() => {}) to all three postMessage() calls. This silently swallows clone failures — the same approach used by broadcast-channel internally for its own message parsing. Cross-tab sync for that specific query update is skipped (the cloned data can't be transferred), but error trackers are no longer polluted and other queries continue syncing normally.

Changes

• packages/query-broadcast-client-experimental/src/index.ts: added .catch(() => {}) to three postMessage() calls (+3 -3 lines)

Testing

• Non-cloneable data in query state: broadcastQueryClient no longer triggers unhandledrejection when setting query data with ReadableStream or Response values ✅
• Normal broadcast: cloneable data (strings, numbers, plain objects) continues to sync across tabs as before ✅
• Multiple queries: only the query with non-cloneable data has its broadcast silently dropped; other queries continue syncing normally ✅