Design safe offline subset reuse and remaining managed-cache recovery contracts
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 5/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- electron, typescript
- Área
- data-engineering
Línea de trabajo
This is a multi-part design issue, not a starting task: the work spans Electric snapshot cursors, the persisted cache wrapper, SQLite durability and legacy storage. Read the linked PR #2069 and issue #2056 first to see the boundary text they establish. Done means a separate, reviewed design per item with its oracle and test coverage, not a single patch.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
PR #2069 makes an invalid on-demand cache safe: it rotates the persisted cache generation and reacquires active subsets. This prevents stale rows from entering a new run, but it does not make a partial Electric cache an authoritative offline snapshot. A later cold start can need the network again. The PR also deliberately leaves several provider, upgrade, and settlement boundaries explicit. Track those product improvements together so each can get a separate design and implementation PR without weakening the safety law.
Work to design and implement
- Certify reusable Electric subsets. Define durable evidence for which predicate/window a source snapshot covers, whether it is exhausted, and which deletes or invalidations have been applied. Specify how overlapping subsets combine, how resume metadata ties to that evidence, and when evidence is revoked. On an offline cold start, publish only rows justified by still-valid coverage. Preserve the current rule that an uncertified partial cache rotates and fetches demanded subsets. Include warm and expired peer runs, empty snapshots, deletes, changed shape identity, and overlapping demands.
- Define the restart contract for other managed on-demand providers. State when a provider must retire old callbacks, settle or reject outstanding demands, start new acquisitions, and fence late results after cache rotation. Keep unsupported providers fail-fast until they opt into and meet the contract. Exercise at least one non-Electric, non-Query implementation through the persisted wrapper.
- Choose a cross-version policy for legacy storage. The first new-format generation uses a different physical ID, so an older tab can still write to legacy tables. Specify the supported mixed-version window and the evidence that makes legacy storage safe to reclaim. Test an old writer racing an upgrade and a later cleanup, including process/tab crashes. Do not infer safety from a schema-version bump alone.
- Resolve publication versus durability after claim expiry. A claim can expire after core publishes a source row but before SQLite accepts its durable write; the receipt then rejects and the Collection fails terminally. Decide whether that fail-stop result is the contract or whether durability-first publication or a defined rollback/reload is required. If recovery is promised, specify caller settlement and public-row observations, then prove the chosen boundary with a real SQLite schedule.
- Enable parallel Electric snapshots only with independent cursor authority. The installed SDK currently shares a mutable snapshot cursor, so serialization is required for correctness. Design separate cursor/session ownership or change the SDK protocol before allowing concurrent snapshots. Test stalled and overlapping requests, cancellation, and late responses against the installed SDK.
Completion criteria
- Record the chosen laws and vocabulary in the cache design, glossary, and user-facing Electric documentation. Distinguish product promises from bounded test evidence.
- For each changed law, extend the primary independent oracle and a receiving test at the provider/SQLite or host boundary. Include a hostile wrong-design control and state remaining unproved schedules in
docs/contributing/oracle-coverage.md. - Preserve eager and progressive Collection behavior and the warm peer's valid rows. No stale row may be published or written under a retired claim.
- Update the PR #2069 boundary text when a follow-up actually lands; this issue does not imply those behaviors already exist.
Related: #2056 and PR #2069.
- Lenguaje dominante
- TypeScript
- Estrellas
- 3.9k
- Forks
- 272
- Merge medio
- 1 d 1 h
- PR fusionados (30 d)
- 210
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de TanStack/db
-
browser-db-sqlite-persistence: option to load the wa-sqlite WASM by URL instead of inlined base64Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
electric-db-collection: on-demand + persistence fails after relaunch with "Snapshot requests are not supported in full mode"Posiblemente ocupada @KyleAMathews la tomó hace 3 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
TanStack/db#2056 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
TanStack/db#1972 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de TanStack/db
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
NousResearch/hermes-agent#136483 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Tool errors containing cycles or BigInt crash getErrorMessage and replace the original failureAbiertofactory-active factory-automatic task-bug-reproduction-success task-identify-harness-labels-done task-identify-issue-type-done
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
vercel/ai#22796 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
[Bug]: Web chat input doesn't regain focus after a reply finishesPosiblemente ocupada @GaijinSystems la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
zeroclaw-labs/zeroclaw#11658 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
babylonlabs-io/babylon-toolkit#2711 ·
Los mantenedores suelen responder en 1 día