Helpfeel専用Cosense Export APIはMongoDB query cursorを閉じ忘れている

Helpfeel エクスポート API のコードを読み込んで、メモリが積み上がりやすい（もしくは実際にリーク扱いされる）箇所を洗い出しました。以下の点を優先的に確認・改善するのがよさそうです。

カーソルを閉じていない

users, events, pages それぞれで Model.find(...).cursor() を開いていますが、streamClosed でループを抜ける際に await cursor.close() していません (src/server/controllers/helpfeel/download-jsonlines.js:74-133)

クライアントが途中で切断すると MongoDB 側にカーソルが残り、サーバーも最後に受け取った 4MB/101 件のバッチを抱えたまま GC 待ちになります。

Helpfeel 側から頻繁に再接続されるケースだと、カーソルとバッチが溜まり続けてメモリリーク同様の症状になります。try/finally で cursor.close() を保証してください。

不要フィールドを全件読み込んでいる

Event でも _id, type, pageId, data.titleLc, created, updated 以外は不要なのに全文取得 (download-jsonlines.js:93-116)。

とくに Page.find(conditions) では lines, links, files, helpfeels 以外の巨大フィールド（infobox, icons, projectLinks など）も全部入ったドキュメントを 1 バッチ 101 件ずつメモリに載せています (download-jsonlines.js:118-146)。各ページが数百 KB〜数 MB になると、バッチ 1 回で数百 MB を消費し、GC が追いつかず「リーク」しているように見えます。.select({ ...必要な

フィールド... }) と .lean() を加えてください。

バッチサイズが大きすぎる

MongoDB のデフォルトバッチは 101 件（または 16MB）。Helpfeel エクスポートは 1 件が大きいので、cursor().batchSize(5) などに下げると瞬間的に保持するメモリを抑えられます。特に Pageで顕著でした。

ユーザー取得の繰り返し

pageToJsonLine 内で await page.getUser() を呼び、ページごとに User.findById と User.findById(lastUpdateUserId) を発行しています (src/server/controllers/helpfeel/download-jsonlines.js:33-69 → src/server/models/page/methods.js:144-189)。ここでもフル Document を 2 件ずつ保持するため、ページ数に比例してメモリが膨らみます。lastUpdateUserId が同じユー

ザーで何度も再取得されるので、Map でキャッシュしつつ .select({ name:1, email:1 }) と .lean() で軽量化すると効果が大きいです。

まずは①カーソルの明示的 close、②.lean().select() の適用、③batchSize の縮小を行うと、Helpfeel エクスポート時の常駐メモリが大幅に下がり、「リーク」の再現度も落ちるはずです。必要であればヒープスナップショット（node --inspect --expose-gc run-server.js → Chrome DevTools）で改善前後を比較すると根拠を示せます。