Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

OfflineExecutor.dispose() never settles pendingTransactionPromises

未关闭 适合新手
  • 哪里不对？
#2,254 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
node.js, typescript
领域
backend, databases

调研方向

从 issue 中链接的 packages/offline-transactions/src/OfflineExecutor.ts 开始，重点查看 waitForTransactionCompletion、resolveTransaction/rejectTransaction 和 dispose()。追踪待处理的 deferred 如何对应到各个 transaction，并检查该 package 的 disposal 测试和 transaction 测试。重现 issue 中的离线 commit、dispose 和 replay 流程；当原始 transaction 进入已结束状态，且其 isPersisted.promise 不再挂起时，即为完成。

由索引模型根据 Issue 内容生成。

描述

  • 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

  1. npm i @tanstack/[email protected] @tanstack/db and save the script below as repro.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.
  2. Start an executor offline and commit a transaction. It persists to the outbox, and the mutation fn does not run.
  3. Call dispose() on that executor and start a successor on the same storage, online.
  4. The successor replays the row, runs the mutation fn once, and empties the outbox.
  5. See that the original transaction still reads persisting and its isPersisted.promise is 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-transactions 1.1.4, @tanstack/db 0.15.2. dispose() is unchanged on main at 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.

主要语言
TypeScript
星标
4k
派生
277
平均合并
17 小时 40 分钟
30 天内合并 PR
223

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

TanStack/db 的其他 Issue

查看 TanStack/db 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。