Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Harden draft saves against a partial failure

オープン
  • 何か問題がありますか？
#321 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
backend

調査の方向性

src/services/projectStorage.ts の、234-241 行目付近にある readAnalysisShard のロジックから始め、次に saveDraft と、その shard、envelope、削除の順序を追ってください。増加するブックセットに対する envelope の書き込み動作を確認し、削除の根拠を再検討してください。完了とは、中断された保存によって名前のないブックではなく古いコンテンツが残り、欠落した shard は消去されず保持されることです。

索引モデルが issue の本文から書いたものです。

説明

enhancement

saveDraft writes every changed shard, then the envelope naming them. A save torn between those two steps leaves a book that this save analyzed for the first time named by no manifest — the old envelope predates it, the new one never landed — so its work is unreachable on reopen.

Writing the envelope with old ∪ new books before the shards would close that: every book stays named throughout, so a torn save yields stale content rather than absent content.

This is safe because a manifest naming a not-yet-written shard is already handled — readAnalysisShard returns readable: false for ENOENT, so the book is held rather than wiped:

https://github.com/sillsdev/interlinearizer-extension/blob/main/src/services/projectStorage.ts#L234-L241

Cost is one extra envelope write, and only when the book set grows.

Field-vs-shard skew is inherent regardless — papi.storage.writeUserData is a plain fs.promises.writeFile, so no single write here is atomic. This only closes the silent-absence case.

Note the delete step's ordering rationale ("deleting only once the envelope has stopped naming the book keeps a failure here from stranding the manifest on a missing shard") would need reworking alongside this, since the envelope would no longer be written exactly once per save.

Raised by @imnasnainaec (drafted by Devin) reviewing #316, and deferred from it as out of scope.

Merged from #322: Revisit the draft save no-retry decision now that a failed save is a partial commit

Before per-book partitioning, the draft was one record: a rejected write was a no-op, leaving the previous draft intact.

Now the analysis spans several records, written before the envelope. A save that fails partway persists a partial state — some books from the new save, the rest from the old one — which stands until the next keystroke triggers another auto-save, and permanently if the user stops editing at that moment.

The next save does repair it: what reached storage is tallied as it lands, so the following save rewrites only the books still missing it. The gap is only that nothing forces a next save to happen.

That makes the documented no-retry decision more expensive than when it was made, which is worth revisiting on its own rather than inside the PR that changed the cost. Options include retrying a failed draft save, or surfacing the failure so the user knows the draft on disk is mixed.

Raised by @imnasnainaec (drafted by Devin) reviewing #316, and deferred from it as out of scope.

主要言語
TypeScript
スター
2
フォーク
0
平均マージ
2日 7時間
マージ済み PR（30日）
45

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sillsdev/interlinearizer-extension のほかの issue

sillsdev/interlinearizer-extension の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。