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

Tell the user what to do when a record's model version is newer than this build

Aperta
  • Qualcosa non va?
#232 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
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
full-stack

Direzione di ricerca

Inizia leggendo il guard della versione del modello da #222 e i suoi chiamanti: listProjects, getDraft, useDraftProject e saveDraft. Traccia il modo in cui i record rifiutati raggiungono il selettore, l’editor e le notifiche localizzate, quindi individua la source of truth per le revisioni esistenti. Il lavoro è completato quando i record supportati più recenti rimangono visibili ma bloccati con un messaggio di aggiornamento, mentre le revisioni impossibili ricevono indicazioni sulla corruzione o sulla risoluzione dei problemi.

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

Descrizione

enhancement

Follow-up to #222, which added modelVersion to every persisted project and draft record and the guard that refuses a record stamped higher than CURRENT_MODEL_VERSION. That guard is deliberately the simple version: assertSupportedModelVersion throws, storage leaves the record untouched on disk, and whatever the caller already does with a failed read is what the user sees. This issue covers making the user's experience of that refusal something other than an unexplained failure.

The scenario is narrow but real:

  • A user has not updated in a while and their build is out of date.
  • They fetch a project a team member has since saved under a newer schema revision.
  • Their build refuses it, correctly — but nothing tells them the fix is to update.

What a user sees today

A newer project disappears from the picker. listProjects logs and skips any record it cannot read, and after #222 a newer record is one of those. The project is simply absent, with the reason only in the log. If it were reached by id instead — the open flow — the refusal surfaces as the generic %interlinearizer_error_load_projects_failed% notification, which says nothing about versions.

A newer draft refusal is silent until the first edit. getDraft throws; useDraftProject logs and falls back to an empty draft, so the editor opens blank with no message. saveDraft then refuses to overwrite the record the read protected, so the first auto-save raises %interlinearizer_error_save_draft_failed% — the right outcome, arrived at confusingly.

Nothing distinguishes "you are out of date" from "this record is damaged." Those two want opposite advice, and the stamp is enough to tell them apart if we know what revisions exist.

Proposed work

  1. Name the case in the UI. A distinct, localized message for a version refusal, separate from the generic load/save failures: this record was written by a newer version of the extension, and updating is what opens it.
  2. Keep a newer project visible in the picker rather than dropping it, marked as needing a newer version and not openable. This is the piece that requires more than a message — listProjects currently has no way to return a record it refused, so it needs a shape that carries "present but unreadable."
  3. Check the stamp against what revisions actually exist. If the stored revision is one a released build understands, prompt to update. If it is higher than any revision that has ever existed, the record is corrupt, not futuristic — point at support or the troubleshooting docs instead. This needs a source of truth for "revisions that exist" that an old build can consult, which is the part worth designing before building.

Priority

Low. Nobody has data written by any build yet, and even once they do this needs a schema bump plus a version skew inside one team to trigger. Filed so the decision is recorded rather than rediscovered when the second revision lands — at which point item 3's data source has to exist before the revision that needs it ships.

Lingua principale
TypeScript
Stelle
2
Fork
0
Merge medio
2g 5h
PR unite (30g)
42

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 sillsdev/interlinearizer-extension

Tutte le issue di sillsdev/interlinearizer-extension

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.