fix(backend): FTTL に歯抜けがあるときタイムラインAPIがDBのノートを取りこぼす問題を修正

[fruitriin]

What

FanoutTimelineEndpointService の最終 DB フォールバック処理が、 DB クエリの境界として Redis 結果の最古 ID を使用していたため、 Redis 上のキャッシュリストの中間にギャップがある (= 本来そこに存在するはずのノート ID が抜けた状態) と、 そのギャップ範囲のノートが DB に存在しても永久に取得不能になっていた。

ps.untilId / ps.sinceId の 全範囲 を DB に問い合わせ、 Redis 由来と重複排除した上で再ソートする方式に変更する。

Before

// まだ足りない分はDBにフォールバック
const remainingToRead = ps.limit - redisTimeline.length;
let dbUntil: string | null;
let dbSince: string | null;
if (ascending) {
  dbUntil = ps.untilId;
  dbSince = noteIds[noteIds.length - 1];
} else {
  dbUntil = noteIds[noteIds.length - 1];  // ← Redis 最古を境界に
  dbSince = ps.sinceId;
}
const gotFromDb = await ps.dbFallback(dbUntil, dbSince, remainingToRead);
return [...redisTimeline, ...gotFromDb];

After

// まだ足りない分はDBにフォールバック
// Redisの最古/最新を境界に使うと、Redis上に中間ギャップ
// (enableFanoutTimelineのON/OFF切り替え、antennas/remove-note等のLREM操作、
//  運用者の手動介入で発生し得る) があった場合に、
// そのギャップ範囲のノートがDBクエリにも含まれず取りこぼされる。
// そのためps.untilId/ps.sinceIdの全範囲をDBに問い合わせ、
// Redis由来のノートと重複排除した上で再ソートする。
const gotFromDb = await ps.dbFallback(ps.untilId, ps.sinceId, ps.limit);
const seen = new Set(redisTimeline.map(n => n.id));
const merged = [...redisTimeline, ...gotFromDb.filter(n => !seen.has(n.id))];
merged.sort((a, b) => idCompare(a.id, b.id));
return merged.slice(0, ps.limit);

Why

enableFanoutTimeline を管理画面から ON → OFF → ON のように切り替える運用 (FTT の挙動調査、 一時的なメンテ、 障害対応等で一般に行われる) を経ると、 OFF 期間中の投稿が Redis 上のキャッシュリストに乗らないまま ON 復帰後の新規投稿だけが追加される状態になる。

その結果として Redis 上に中間ギャップが生じ、 現状の最終 DB フォールバックの境界式 (Redis 最古 ID を dbUntil に使う) では、 そのギャップ範囲のノートが DB クエリにも含まれず、 タイムライン API のレスポンスから永久に欠落する。

詳細・再現手順 (UI 操作)・原因・用語解説は Issue #XXXXX 参照。

Additional info (optional)

Tests added

packages/backend/test/e2e/timelines.ts に新 describe ブロック FTT Redis gap fallback を追加 (3 ケース):

1. Home TL: homeTimeline Redis リスト 20 件中 中間 7 件を LREM で削除して中間ギャップを作り、 notes/timeline (limit=20) で DB の全 20 件が返ることを確認
2. Channel TL: 同様に channelTimeline のギャップで channels/timeline (limit=20) を検証
3. Channel TL 連続ページネーション: 60 件投稿 + 中間 7 件ギャップ で 4 ページ走査により 60 件すべて取得できることを確認

テストでは LREM で人為的に Redis 状態を作っているが、 Issue 本文のとおり管理画面の enableFanoutTimeline トグル ON → OFF → ON で同じ状態を作ることもできる。

修正前後の検証結果

ケース	修正前	修正後
Home TL untilId 未指定 (limit=20)	NG (7 件 missing)	OK (20/20)
Channel TL untilId 未指定 (limit=20)	NG (7 件 missing)	OK (20/20)
Channel TL 連続ページネーション (60 件)	NG (53/60、 7 件スキップ)	OK (60/60)

Trade-off

最終フォールバックパスで DB クエリの limit が remainingToRead から ps.limit に増える分のコスト。 ただし元コードでも最終フォールバックで DB を叩いており、 追加コストは限定的。 正しさを保証する代償として妥当と判断。

useDbFallback=false の場合は ps.dbFallback = () => Promise.resolve([]) に置換されるため (FanoutTimelineEndpointService.ts:73)、 修正後も追加 DB クエリは発生しない (既存運用設定を尊重)。

Affected endpoints

FanoutTimelineEndpointService.timeline を呼ぶ全 endpoint:

• notes/timeline (HTL)
• notes/local-timeline (LTL)
• notes/hybrid-timeline
• channels/timeline
• notes/user-list-timeline

なお antennas/notes 等は FanoutTimelineEndpointService を経由せず独自実装なので、 本 PR の修正は影響しません。

Related

• Issue: enableFanoutTimeline をトグルすると、 タイムラインからノートが取りこぼされる #17547 enableFanoutTimeline をトグルすると、 切り替え前後の投稿の間に Redis 上で時系列ギャップが残り、 タイムラインからノートが取りこぼされる fruitriin/misskey#38
• 関連 PR (過去の FTT 修正): #16284 (FTT バグ修正 + テスト), #17251 (チャンネルミュート関連修正)

Checklist

• Read the contribution guide
• Test working in a local environment
• (If needed) Update CHANGELOG.md
• (If possible) Add tests

[github-actions]

このPRによるapi.jsonの差分
差分はありません。
Get diff files from Workflow Page

[codecov]

Codecov Report

❌ Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 22.40%. Comparing base (e2bcd9c) to head (a75591b).
⚠️ Report is 5 commits behind head on develop.

Files with missing lines	Patch %	Lines
.../backend/src/core/FanoutTimelineEndpointService.ts	0.00%	5 Missing and 3 partials ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #17549      +/-   ##
===========================================
+ Coverage    15.14%   22.40%   +7.25%     
===========================================
  Files          248     1159     +911     
  Lines        12412    39593   +27181     
  Branches      4214    11033    +6819     
===========================================
+ Hits          1880     8870    +6990     
- Misses        8241    24666   +16425     
- Partials      2291     6057    +3766     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[anatawa12]

#13495 とある程度被る感じかな

FTTを on => off => on のときは on => off のタイミングで全て FTT を消すとかの方が対処として良さそうな気もする

EDIT: 消すのは #17548 か

[github-actions]

Backend memory usage comparison

Before GC

Metric	base (MB)	head (MB)	Diff (MB)	Diff (%)
VmRSS	306.56 MB	307.49 MB	+0.93 MB	+0.30%
VmHWM	306.56 MB	307.49 MB	+0.93 MB	+0.30%
VmSize	23173.16 MB	23172.09 MB	-1.07 MB	0%
VmData	1373.22 MB	1372.64 MB	-0.58 MB	-0.04%

After GC

Metric	base (MB)	head (MB)	Diff (MB)	Diff (%)
VmRSS	306.73 MB	307.50 MB	+0.76 MB	+0.25%
VmHWM	306.73 MB	307.50 MB	+0.76 MB	+0.25%
VmSize	23173.33 MB	23172.26 MB	-1.07 MB	0%
VmData	1373.39 MB	1372.80 MB	-0.58 MB	-0.04%

After Request

Metric	base (MB)	head (MB)	Diff (MB)	Diff (%)
VmRSS	307.13 MB	307.98 MB	+0.85 MB	+0.27%
VmHWM	307.13 MB	307.98 MB	+0.85 MB	+0.27%
VmSize	23173.41 MB	23172.34 MB	-1.07 MB	0%
VmData	1373.47 MB	1372.89 MB	-0.58 MB	-0.04%

See workflow logs for details

[fruitriin]

あー、 #13495 に気づいてなかったけど、やりたいことが全く同じっぽい

原因が全く異なる模様

[fruitriin]

このPRでは 同一ソース内の歯抜けの対処なので、 #13495 の目的ケースでは救えないものが救えたりするし、 #13495 がないと救えないものがあるっぽい
ただコンフリクトはする模様