Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Electric progressive: apply and confirm changes to visible rows during the background full sync

Aperta
  • Qualcosa non va?
#2,120 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend, database

Direzione di ricerca

Start with packages/electric-db-collection/src/electric.ts and the progressive witnesses in electric-live-query.test.ts; trace how buffered changes, snapshot metadata, txid evidence, and the atomic swap interact. Use the recovery and descriptor-isolation oracles to check ordering around snapshot xmin, xmax, and xip, then inspect persistence and reset behavior. Done means visible-row changes and their txids are applied before the swap, with no stale rollback or duplicate application, and the stated evidence passes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

During a progressive collection's background full sync, Electric buffers stream changes and their txids until the atomic swap. #2115 makes a live query over a progressive source ready as soon as its own subset loads. A user can now edit a visible row while the full sync is still running. That mutation's awaitTxId cannot resolve until the swap. If the full sync takes longer than the awaitTxId timeout, the handler throws and the optimistic change rolls back.

The stream starts at once, so Electric receives the confirming change long before the swap. Electric could apply that change and its txid during buffering for rows that the client already shows.

Current behavior

In packages/electric-db-collection/src/electric.ts:

  • While isBufferingInitialSync() is true, change messages go to bufferedMessages. Their txids are not added to newTxids. The comment says "txids will be extracted during atomic swap".
  • The atomic swap on the first up-to-date applies the buffered changes, extracts their txids, and then resolves txid waiters through publishEvidence.

As a result:

  1. Confirmation waits for the full sync. awaitTxId(txid) for a write to a visible row resolves only at the swap.
  2. Visible rows go stale. A ready progressive query shows its subset snapshot rows unchanged until the swap. #2115 records this as a known limit, and electric-live-query.test.ts pins it ("a ready query's rows update only when the full sync completes").

Before #2115, useLiveQuery already rendered rows in this window. Suspense users now reach it too.

Proposal

Apply stream changes during buffering for keys that a subset snapshot already loaded, when the change is newer than that snapshot. Record their txids when the change applies. Keep buffering every other change until the swap.

Electric has the needed pieces:

  • progressiveSnapshotRows keeps the snapshot row for a key when a later stream update needs that row as its baseline.
  • Each fetchSnapshot returns snapshot metadata, and isVisibleInSnapshot can order a txid against it.

The txid must resolve only when its change is visible. If Electric confirms a change that it still buffers, the optimistic state drops and the old snapshot row shows again until the swap.

Questions to settle

  • Ordering. A change can be older than, or included in, the snapshot that loaded its key. Use the snapshot's xmin, xmax, and xip list to decide whether to apply the change, skip it as already included, or keep buffering it.
  • The swap. The swap must not apply an early-applied change a second time, and it must not move a row back to an older value.
  • Keys outside any subset. Changes to keys that no subset loaded stay buffered, so their txids stay unconfirmed until the swap. Decide whether awaitTxId should report this case, or whether a write to a row the client never loaded is outside scope.
  • Must-refetch. A reset during buffering discards the subset rows. Changes applied early before the reset must follow the reset's truncate rules.
  • Persistence. Early-applied changes go through the same commit and receipt path. Check resume metadata and seenTxids evidence for persisted collections.

Evidence to add

  • Extend the progressive witnesses in electric-live-query.test.ts. A write to a visible row during buffering must become visible, and its awaitTxId must resolve before the swap.
  • Flip the pinned freshness test on purpose, and update the limit in packages/db/src/query/live/ARCHITECTURE.md and in the #2115 review record.
  • Add an ordering lane with changes before, inside, and after the loading snapshot, checked against an independent model. The Electric recovery and descriptor-isolation oracles already generate progressive histories and are a good place to start.
  • A hostile control: a design that confirms a txid without applying its change must fail at the first checkpoint after confirmation.

Related: #2113, #2115, #2118.

Lingua principale
TypeScript
Stelle
3.9k
Fork
272
Merge medio
1g 1h
PR unite (30g)
235

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di TanStack/db

Tutte le issue di TanStack/db

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.