writeUpsert / writeBatch path has no error propagation to useLiveQuery consumers

[Danny-Devs]

Problem

The query-collection docs recommend writeUpsert / writeBatch for WebSocket-driven updates — "Direct writes bypass this system entirely and write directly to the synced data store, making them ideal for handling real-time updates from alternative sources."

When the upstream fetch that feeds writeUpsert fails, there's no way to propagate that error to useLiveQuery consumers.

QueryCollectionUtils exposes isError, lastError, errorCount, and clearError() — but these only reflect queryFn failures flowing through the TQ QueryObserver. writeUpsert bypasses the bridge entirely, so its failures are invisible to the collection's error lifecycle.

The result: a failed WS-triggered fetch means writeUpsert is never called, the collection doesn't know anything went wrong, and useLiveQuery returns no data and no error. The component shows a loading spinner indefinitely.

queryFn fails           → collection status = 'error'  ✅  (via QueryObserver)
writeUpsert fetch fails → collection status = 'loading' ❌  (no error channel)
                        → useLiveQuery: { data: [], isError: false, isLoading: true }
                        → component: infinite spinner

Current workaround

We maintain a separate reactive error store outside TDB (Map<entityId, { message, timestamp }>) and wire it into every composable manually. Each composable that reads from a WS-driven collection adds ~10 lines of boilerplate to read from both pipes (TDB for data, the error store for errors) and merge them:

const syncError = computed(() => syncErrors.value.get(entityId))
const isLoading = computed(() => !!id && liveQueryLoading.value && !syncError.value)
const isError = computed(() => !!syncError.value)
const error = computed(() => syncError.value?.message ?? null)

This works but scales linearly with the number of WS-driven entities — every composable repeats it.

Suggestion

An API like collection.utils.reportError(key, error) that sets the collection into the same error state that a queryFn failure would — so useLiveQuery consumers see isError: true through the same channel. Or a writeError(key, error) alongside writeUpsert.

Related

• Fetching state for on-demand collections (for use with useLiveQuery) #1111 — ambiguous loading/empty states for on-demand collections (same root cause: useLiveQuery can't distinguish "loading" from "failed")