TanStack/db @tanstack/offline-transactions@1.1.0

on GitHub

Minor Changes

• Add OfflineConfig.shouldRetry so an app can retry an offline transaction after (#1592)
  its named mutation function rejects with a recoverable error, such as a 401.
  Return undefined to use the default decision. NonRetriableError remains
  terminal, and retry timing stays the same. The hook returns synchronously and
  applies to all named mutation functions.
  If the hook fails, the executor removes only that outbox row and rejects its
  waiters; queued transactions continue after terminal cleanup.

Patch Changes

• Stop tracking a transaction after it fails or rolls back. Before, a Collection kept every failed or rolled-back transaction, including a rolled-back offline restoration, until the Collection was cleaned up. Each later mutation walked all of them, so a mutation got slower with each rollback the Collection had seen (about 20× after 4,000 rollbacks), and the failed transactions kept their rows in memory. A settled transaction now leaves the Collection in the recompute that publishes its settlement, and removing it never removes a later transaction that reuses its id. (#2080)

  A settled transaction leaves every Collection that tracked it, including a Collection whose mutations merged away, a second Collection instance with the same id, and a Collection whose transaction rolled back during a sync commit.

  When a subscriber throws during settlement, every Collection still recomputes and isPersisted still settles, including when the throw comes from a conflicting transaction that the rollback also rolls back. The call then rethrows one of the subscriber errors. Before, a throw could leave other Collections showing the settled transaction's optimistic rows, and a throw from a conflicting rollback left the primary transaction's isPersisted pending.

  A settled transaction no longer keeps the set of Collections that tracked it; its mutations still name their Collection. Offline restoration now tracks and releases its transaction through the same path as other transactions. A completed restoration settles its isPersisted, and a restoration that one Collection cannot track is rolled back so no Collection keeps its rows.

  Repeated mutate() calls on one offline transaction now add to the same transaction. Before, each call created a new transaction with the same id, which replaced the earlier one and hid its rows. With autoCommit (the default), the first call commits, so a later call throws TransactionNotPendingMutateError, as mutate() does on any committed transaction. Create a new offline transaction for each auto-committed write.

  When a mutation function rejects and a subscriber also throws during the rollback, commit() now rejects with the mutation error. Before, it rejected with the subscriber error and the mutation error was lost.

  Transaction ids must be unique among unsettled transactions. A write that would make a Collection track a second unsettled transaction with an id it already tracks now throws DuplicateTransactionIdError and changes nothing. Before, the second transaction silently replaced the first, whose optimistic rows disappeared while it was still pending. Settling a transaction also no longer removes a different pending transaction that shares its id from conflict tracking.

• Updated dependencies [f6aba31, faa3de6, bcb2af6, 2ab7f3e, 86f00ea, f7ac2c6, fa36267, 2c98b49, f6d65ea, fe284cc, 8b0e1de, 4bd66cf]:

  • @tanstack/db@0.13.0