Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#232 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
typescript
Lĩnh vực
full-stack

Hướng nghiên cứu

Bắt đầu bằng cách đọc guard phiên bản model từ #222 và các hàm gọi nó: listProjects, getDraft, useDraftProject và saveDraft. Theo dõi cách các bản ghi bị từ chối đến picker, editor và các thông báo đã bản địa hóa, sau đó xác định source of truth cho các revision đang tồn tại. Được xem là hoàn tất khi các bản ghi mới hơn nhưng được hỗ trợ vẫn hiển thị nhưng bị chặn kèm thông báo cập nhật, còn các revision không thể xử lý nhận được hướng dẫn về dữ liệu hỏng hoặc khắc phục sự cố.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
2
Fork
0
Merge trung bình
2 ngày 3 giờ
Pull request đã merge (30 ngày)
46

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sillsdev/interlinearizer-extension

Tất cả issue của sillsdev/interlinearizer-extension

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.