Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[claude] Detect and recover when OpaqueChanges become applicable

Abierto
  • ¿Algo no está bien?
#90 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
csharp
Área
databases, distributed-systems

Línea de trabajo

Empieza leyendo CrdtRepository.AddCommits, SnapshotWorker y las rutas existentes RegenerateSnapshots, DeleteStaleSnapshots y UpdateSnapshots. Compara las alternativas propuestas de seguimiento de agregados y huellas digitales con el comportamiento de commit-log y ChangeEntities descrito aquí. Done debe incluir un alcance de detección decidido, el tratamiento de las bases de datos existentes y una forma de informar de un estado materializado incompleto sin regenerarlo silenciosamente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Data bug

[Claude, autonomous]

Problem

Since #80, a change with an unknown $type is stored and synced onward as an OpaqueChange, but SnapshotWorker skips applying it. Snapshots and projected tables are then silently missing its effect, and:

  • When the app later registers the type, nothing notices. The stored JSON would now deserialize concretely, but snapshots are never re-folded, so the stale state persists forever.
  • Some types will never become known (a different app writing to the same project). That's a legitimate steady state, but a client currently can't even answer "is my materialized state incomplete?", which matters for consumers that write materialized state into other systems (FwHeadless → FieldWorks).
  • If the first change to an entity is opaque, no snapshot exists, so later known changes to that entity are skipped too.

Recovery itself is the easy part: the commit log is complete everywhere (opaque JSON round-trips verbatim), so RegenerateSnapshots() already repairs state once the type is registered. What's missing is detection, and ideally a cheaper replay scope than "everything".

One idea: an UnappliedChangeTypes table

One aggregate row per unknown discriminator, written at commit ingest (CrdtRepository.AddCommits, same transaction): TypeName (PK), EarliestCommitId, ChangeCount.

  • Detection = intersect TypeNames with registered discriminators at project open. Non-empty: replay from the predecessor of the earliest affected commit (the existing DeleteStaleSnapshots + UpdateSnapshots path), then delete the recovered rows.
  • Never-known types never intersect; their rows sit inert and double as a cheap "this project has changes I can't apply" signal for UI or sync guards.
  • Existing DBs backfill with one json_extract(Change, '$."$type"') scan over ChangeEntities.

Ingest is deliberate: the converter also runs on read paths, and the SnapshotWorker skip sites also fire for ordinary out-of-order arrivals, so ingest is the only place that sees each commit exactly once.

Alternatives

Persist nothing; fingerprint the registered type set. On growth, scan history for the new types; regenerate if found.

  • Pro: zero bookkeeping, fully retroactive.
  • Con: a scan every release that adds a type; "am I incomplete right now?" also costs a scan; the registered set can differ per host (e.g. conditional AddRemoteResourceEntity), so set comparison needs care.

Per-skip rows (CommitId, ChangeIndex, TypeName, EntityId).

  • Pro: exact.
  • Con: unbounded in the never-known steady state; no benefit over the aggregate, since replay is scoped by earliest commit, not per change; only records skips after it ships, so it needs the backfill anyway.

Regenerate whenever the registered type set changes.

  • Pro: no detection code.
  • Con: full replay after nearly every release; RegenerateSnapshots is currently unlocked, non-transactional, and slow on big projects, so everyone pays for a rare event.

Do nothing; rely on the manual regenerate troubleshooting action.

  • Pro: zero code.
  • Con: staleness is silent, so nobody knows to press the button; FwHeadless would sync stale state indefinitely.

Notes

  • Whichever way this goes, it should land in the same release as #80 or close behind: builds that skip changes without recording anything leave stale snapshots that later detection can't tell from a clean DB without the backfill scan.
  • Auto-regeneration should wait until RegenerateSnapshots is locked, transactional, and fast enough. Detection plus a visible warning is already useful on its own.

Context: sillsdev/languageforge-lexbox#2482 (review discussion that prompted this).

Lenguaje dominante
C#
Estrellas
14
Forks
4
Merge medio
5 d 15 h
PR fusionados (30 d)
10

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sillsdev/harmony

Todos los issues de sillsdev/harmony

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.