taichan
taichan
2023.12.0まではページ名が出ていたので https://github.com/misskey-dev/misskey/pull/13289 この辺りが怪しいのではないかと踏んでいる
具体的に原因調査しようと思ったけど自分では力量不足だった
@taiyme アサイン致しました。よろしくお願いいたします！
related: https://github.com/misskey-dev/misskey/pull/11938
センシティブ判定のすり抜けも起こる？（投稿範囲のアップデートが行われないため）
検索のインデックスがおそらく変更前のノートに基づく
とりあえず暫定としてやったほうがよさそうなこと - 編集画面が作成画面と同一のため色々な問題がある - 編集画面でtextとcwを弄れないようにする、連合しない旨を注釈つける これやるだけで一旦色々言われている諸問題は片付く気がしている
確かにそうですね！（現在多忙な上に諸事情がありすぐに反映できないかもしれないですがそのほうがパフォーマンス上良さそうなので試してみます） （ユーザーTLもこの実装を利用しているのをやや忘れていました…）
少し思考が散らかっているのでメモ書きです （※ここでのDBはPostgreSQLないしRDBを指す） 改めて考えてみているけど一度もファイルをアップロードしていないかどうかはDBを見てみないとわからなくて（FTTのキャッシュがredisの内容が飛ぶなどの理由で不十分な場合もある）、もう一度残った部分のFTTを参照するだけではDBには存在するのにFTTには存在しないノートがあるかどうか（つまり取得漏れがあるかどうか）がわからない FTTにないだけでDBにはノートがあるケースは割とredisが揮発するものである前提からして（またCacheにMaxが定められているのも含め）起きそうなので悩ましい 全くDBを参照させないというのは仕組み上難しそう（これがそもそも複数のTLのキャッシュが残っている幅の差分の間でフォールバックがきちんと効くようにするPRという趣旨なのもある） そのFTTソースに対応する条件のノートがDBに本当に存在しないかを確かめるには少なくともCOUNT句か何かでDBを見て比較自体はしないと結局問題が解決しない気がする もう一度FTTのうちのページングで取得するだけでは取得漏れをきちんと漏らさないことは実現不可能なのでは…？
そもそもFTTに含まれていないノートをDBから持ってくるという趣旨なのでFTTが空な場合にフォールバックするのは自然ではある気がしてきた、ただ一度もファイルを投稿していなければFTTが空で常にフォールバックが起こってしまう（DBへの負荷を減らすためのFTTなのに効果が弱くなる）というのは理解できるのでどうやって落とし所つけようかしら…