Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

sqlite-persistence: leader term write on every page load delays reading rows

Fermée
  • Quelque chose ne va pas ?
#2,205 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Une pull request liée a déjà été fusionnée.

  • #2219 par @KyleAMathews — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
50/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
sqlite, typescript
Domaine
database, performance

Piste de recherche

Start in BroadcastCollectionCoordinator, where the issue says collection election and term reservation occur, and trace subscribe through ensureCollectionState to acquireLeadership. Then follow the listed route waits and first-read completion path to see where ensureLeadership could start election; compare the two described patch shapes. Done means rows can be read before an eager collection reserves its term, while route waits still trigger election and terms, locks, and heartbeats retain their behavior.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

  • I've validated the bug against the latest version of DB packages
Describe the bug

Every page load, each persisted collection starts leader election as soon as it subscribes (subscribe → ensureCollectionState → acquireLeadership) and reserves a new term, a durable write, even though nothing has asked for a leader yet. On the browser OPFS adapter the driver runs one operation at a time and a transaction counts as one, so the term transaction sits in the queue ahead of the rows being read. Eager collections don't need a leader to read their rows, so this is time spent waiting on a write they don't use yet.

Trace of one collection's term on a reload (start ms, duration ms):

181.1  0.9  BEGIN IMMEDIATE
182.0  0.6  SELECT schema_version FROM collection_registry …
182.6  3.9  INSERT INTO leader_term (collection_id, latest_term) VALUES (?, ? + 1) ON CONFLICT …
186.5  0.4  SELECT latest_term FROM leader_term …
186.6  0.4  SELECT MAX(seq) AS max_seq FROM applied_tx …
186.6  0.6  SELECT latest_row_version FROM collection_version …
187.2  5.0  COMMIT
192.2  0.7  BEGIN IMMEDIATE
193.1  0.4  SELECT key, value, metadata, row_version FROM "c_qvzbpr_8"

That's about 11 ms for this collection, and every collection pays it before its rows are read.

To reproduce
  1. @tanstack/browser-db-sqlite-persistence 0.2.36, @tanstack/db-sqlite-persistence-core 0.4.11
  2. OPFS database, 8 persisted collections (syncMode: "eager", schemaVersion: 1, BrowserCollectionCoordinator), all preloaded at once, fill them once, reload
  3. Log the database's execute calls
Expected behavior

Start a collection's election the first time it needs a leader instead of when it subscribes: when its first read finishes, or when something waits for a route (requestEnsureRemoteSubset, requestApplyCommittedTx, requestApplyLocalMutations, reconcileCommittedTx). Terms, locks and heartbeats stay as they are, only the timing changes.

Every route wait would need to start the election through ensureLeadership, or a single tab could wait for a leader that never gets elected. A first write would then wait for the read plus the term instead of just the term, a few ms.

A second option: keep electing at subscribe, but send the term write through the shared scheduler, so it waits behind reads that are already queued. I'm less sure of this one. A comment in main says election skips the scheduler on purpose, because a hydrate can be waiting for its first writer route. If the term write queued behind that hydrate, each would wait for the other. My test has no remote sync, so it never hit that case. The first option avoids it.

Numbers

Both shapes take 18–26 ms off the time until the first three collections have read their rows from disk, and both keep every term write.

I tried both as small patches to BroadcastCollectionCoordinator: one starts a collection's election once its first read finishes, the other runs reserveLeadershipTerm through adapter.runInRegularScope. Headless Chromium, 8 collections, 3 runs of 15 reloads, all variants alternating. Medians in ms from creating the collections until their rows were read.

First 3 collections read:

Run Election after first read Term through the scheduler
1 134 → 108 (−26) 134 → 113 (−21)
2 133 → 110 (−23) 133 → 107 (−26)
3 129 → 110 (−19) 129 → 111 (−18)

All 8 read:

Run Election after first read Term through the scheduler
1 234 → 213 (−21) 234 → 224 (−10)
2 237 → 228 (−9) 237 → 214 (−23)
3 234 → 214 (−20) 234 → 215 (−19)
Desktop

Headless Chromium 141 on Linux.

Additional context

Related to #2204, which is about the table setup each collection runs on the same path.

Happy to send a PR with an oracle test if you want this.

Langage dominant
TypeScript
Étoiles
4k
Forks
277
Merge moyen
21 h 21 min
PR mergées (30 j)
218

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TanStack/db

Toutes les issues de TanStack/db

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.