OfflineExecutor.dispose() never settles pendingTransactionPromises
Maintainer antworten meist innerhalb von 1 Tag
@Claire-ovo arbeitet bereits daran.
Seit 26.10.2026.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 78/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- node.js, typescript
Rechercherichtung
Beginne mit packages/offline-transactions/src/OfflineExecutor.ts, insbesondere mit waitForTransactionCompletion, resolveTransaction/rejectTransaction und dispose(), wie im Issue verlinkt. Verfolge, wie ausstehende Deferreds den Transaktionen zugeordnet sind, und prüfe die Disposal- und Transaktionstests des Pakets. Reproduziere die im Issue beschriebene Abfolge aus Offline-Commit, Disposal und Replay; als abgeschlossen gilt die Aufgabe, wenn die ursprüngliche Transaktion einen abgeschlossenen Zustand erreicht und ihr isPersisted.promise nicht mehr hängen bleibt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
- I've validated the bug against the latest version of DB packages
Describe the bug
OfflineExecutor keeps a pendingTransactionPromises map of deferreds, created by waitForTransactionCompletion and settled by resolveTransaction / rejectTransaction. dispose() pauses the executor and tears down the collection refresh hooks, the online listener, leadership, and the online detector, but it never touches the map. Every deferred in it is abandoned, so a transaction committed on a disposed executor never leaves persisting, and its isPersisted.promise never settles.
To Reproduce
npm i @tanstack/[email protected] @tanstack/dband save the script below asrepro.mjs. It runs in plain Node: in-memory storage stands in for IndexedDB and is shared by both executors, and connectivity and leader election are stubbed.- Start an executor offline and commit a transaction. It persists to the outbox, and the mutation fn does not run.
- Call
dispose()on that executor and start a successor on the same storage, online. - The successor replays the row, runs the mutation fn once, and empties the outbox.
- See that the original transaction still reads
persistingand itsisPersisted.promiseis unsettled (node repro.mjs --dispose). The control run without the dispose resolves (node repro.mjs).
repro.mjs
import { createCollection, localOnlyCollectionOptions } from "@tanstack/db";
import { startOfflineExecutor } from "@tanstack/offline-transactions";
const withDispose = process.argv.includes("--dispose");
// Shared in-memory storage, standing in for IndexedDB across both executors.
const store = new Map();
const storage = {
get: async (k) => store.get(k) ?? null,
set: async (k, v) => void store.set(k, v),
delete: async (k) => void store.delete(k),
keys: async () => [...store.keys()],
clear: async () => void store.clear(),
};
// Always-leader election: no Web Locks in Node.
const leaderElection = {
requestLeadership: async () => true,
releaseLeadership: () => {},
isLeader: () => true,
onLeadershipChange: () => () => {},
};
// Manually toggled connectivity.
function makeDetector(initiallyOnline) {
let online = initiallyOnline;
const listeners = new Set();
return {
subscribe: (cb) => (listeners.add(cb), () => listeners.delete(cb)),
notifyOnline: () => listeners.forEach((cb) => cb()),
isOnline: () => online,
dispose: () => listeners.clear(),
goOnline() {
online = true;
listeners.forEach((cb) => cb());
},
};
}
const todos = createCollection(
localOnlyCollectionOptions({ id: "todos", getKey: (t) => t.id }),
);
const calls = [];
const mutationFns = {
syncTodos: async ({ transaction }) => {
calls.push(transaction.id);
},
};
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const settledWithin = (promise, ms) =>
Promise.race([
promise.then(
() => "resolved",
(e) => `rejected: ${e?.message}`,
),
sleep(ms).then(() => "STILL PENDING"),
]);
// 1. Start offline and commit a transaction; it persists to the outbox.
const detector1 = makeDetector(false);
const executor1 = startOfflineExecutor({
collections: { todos },
mutationFns,
storage,
leaderElection,
onlineDetector: detector1,
});
await executor1.waitForInit();
const tx = executor1.createOfflineTransaction({ mutationFnName: "syncTodos" });
// autoCommit defaults to true, so mutate() commits.
const transaction = tx.mutate(() => todos.insert({ id: "1", text: "hello" }));
const isPersisted = transaction.isPersisted.promise;
await sleep(100);
console.log("outbox rows after offline commit:", store.size);
console.log("mutationFn calls while offline:", calls.length);
let completer;
if (withDispose) {
// 2. Dispose (the recreate pattern) and start a successor on the same storage.
executor1.dispose();
const detector2 = makeDetector(true);
completer = startOfflineExecutor({
collections: { todos },
mutationFns,
storage,
leaderElection,
onlineDetector: detector2,
});
await completer.waitForInit();
} else {
// Control: no dispose, just come back online on the same executor.
detector1.goOnline();
completer = executor1;
}
// 3. Let the outbox drain.
await sleep(500);
console.log("mutationFn calls after replay:", calls.length);
console.log("outbox rows after replay:", store.size);
console.log("pending count on completing executor:", completer.getPendingCount());
// 4. The promises the first executor handed out.
console.log("transaction.state:", transaction.state);
console.log("isPersisted.promise:", await settledWithin(isPersisted, 2000));
process.exit(0);
Output:
== node repro.mjs (control: no dispose)
outbox rows after offline commit: 1
mutationFn calls while offline: 0
mutationFn calls after replay: 1
outbox rows after replay: 0
pending count on completing executor: 0
transaction.state: completed
isPersisted.promise: resolved
== node repro.mjs --dispose
outbox rows after offline commit: 1
mutationFn calls while offline: 0
mutationFn calls after replay: 1
outbox rows after replay: 0
pending count on completing executor: 0
transaction.state: persisting
isPersisted.promise: STILL PENDING
Expected behavior
dispose() settles every deferred in pendingTransactionPromises, so no caller is left awaiting a transaction from a disposed executor. Either of these would work:
- Reject each deferred with a disposal error the caller can treat as retriable.
- Expose the pending ids so a successor executor can re-bridge them, and resolve them when it completes the replayed transaction.
Screenshots
N/A. The repro's console output is above.
Desktop (please complete the following information):
- OS: Linux (kernel 6.18)
- Browser: N/A. Reproduced in Node v24.22.1. The executor code path is environment-independent.
- Version:
@tanstack/offline-transactions1.1.4,@tanstack/db0.15.2.dispose()is unchanged onmainat d2935d0.
Smartphone (please complete the following information):
- N/A
Additional context
I first hit this on 1.0.42 in an app whose outbox recreates its executor whenever a new collection registers. I work around it with a completion ledger that carries isPersisted settlement across the recreate, but an upstream fix would let me delete this workaround.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 4k
- Forks
- 277
- Ø Merge
- 21 Std. 21 Min.
- Gemergte PRs (30 T.)
- 218
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus TanStack/db
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Two @tanstack/db tests time out under CPU load because a cold module import counts against the 5 s default timeoutEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 58/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
Maintainer antworten meist innerhalb von 1 Tag
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
vekexasia/pi-extensible-workflows#374 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
documentation good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 77/100
Maintainer antworten meist innerhalb von 1 Tag
-
help wanted linux
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
GiuseppeBellamacina/downtime#19 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
scaleway/ultraviolet#7089 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Get-Concord-AI/concord-mcp#296 ·
Maintainer antworten meist innerhalb von 1 Tag