エージェント型の開発環境。

アップロードキューに指数バックオフを追加しました。失敗したチャンクは最大5回まで再試行し、進捗バーに試行回数を表示します。テストはタイムアウトと 503 のケースをカバーしています。

これまで失敗したチャンクは捨てられていました。いまはキューがバックオフポリシーに待ち時間を問い合わせて再試行を予約するので、すべての再試行が1か所を通ります。

5 回失敗するとチャンクは確定で失敗扱いになり、アップロードは明確なエラーで止まります。切れた回線で再試行が続くことはありません。

キューの変更は src/upload/queue.ts に、待ち時間の設定は src/upload/backoff.ts にあります。

キューは各チャンクの状態をディスクに書き込むようになりました。いま再起動時の処理をつないでいます。

起動時にキューが保存済みの状態を読み、未完了のチャンクだけを送るので、2 GB のファイルも最初からやり直しません。

戦略には市場に出るとあったので、そのための関数を追加しました。

1export async function goToMarket() {2  await ship();3  await tellDenis();4}

テストは 1 件通っています。市場からの返事はまだありません。

ウォッチャーが書き込む前にテストがファイルを読んでいました。flush イベントを待つようにしたところ、200 回連続で通っています。

1test('reads the synced file', async () => {2  await writeFile(path, 'hello');3  await watcher.flushed(path);4  const text = await readFile(path);5  expect(text).toBe('hello');6});

待機はテストヘルパーに入れたので、ほかの同期テストにも効きます。

新しいページはできました。タブを削除する前に設定の移行を実行する必要があります。

指摘が 2 つあります。セッション Cookie に有効期限がなく、ログイン後のリダイレクトが任意の URL を受け付けます。ほかは問題ありません。

クリーンな環境で新しいコマンドを試し、動作を確認しました。

1bun add -g uploader2uploader --help

古い curl コマンドも動くので、代替手段として残せます。

時間の大半は検索のたびに全ファイルを読むことに使われています。インデックスで短縮でき、小さなリポジトリはほとんど変わりません。

インデックスはファイルが変わると更新されるので、全体の再構築は不要です。

ツリーはディスクのキャッシュから読み込み、バックグラウンドで更新します。変わるのは待ち時間だけです。

ブランチが変わるとキャッシュは自動で消えます。

見つけました。空のファイルは null になり、コードがすぐそのフィールドを読んでいます。

1export function loadConfig(path: string) {2  const text = readFileSync(path, 'utf8');3  if (text.trim() === '') return defaults;4  return { ...defaults, ...parse(text) };5}

いまは空のファイルを既定の設定として扱い、壊れたファイルには明確なエラーを出します。

新しい issue は 5 件です。3 件は本物のバグで、そのうち 1 件は次のリリースまで待てます。

すべてにラベルを付け、重複は古い報告にリンクしました。