clips/my-favoritesのページネーションが正しく動作していない
💡 Summary
#16835 の後、 clips/my-favorites はクリップをお気に入りに登録した順に返すようになりました。そのため、 untilId や sinceId にはクリップのお気に入りのidを渡すべきですが、この情報はフロントエンドからは利用できません。
現在のフロントエンドではクリップのidが渡されており、そのためすべてのお気に入りしたクリップを読み込むことができなかったり、一部のクリップが繰り返し読み込まれたりすることが起こります。
この問題に近い問題として #12175 でフォローしたチャンネルの一覧を取得するときにフォローのidではなくチャンネルのidが使われたことでページネーションが壊れたことがありました。
ref: https://github.com/misskey-dev/misskey/pull/13698#issuecomment-2155732248
🥰 Expected Behavior
次のいずれか
clips/my-favoritesがクリップの作成順でお気に入りしたクリップを返す- #13698
v2/clips/my-favoritesがClipFavoriteを返す- https://github.com/misskey-dev/misskey/issues/12175#issuecomment-1783982399
- https://github.com/misskey-dev/misskey/pull/13698#issuecomment-2848464336
- https://github.com/misskey-dev/misskey/issues/14219
🤬 Actual Behavior
新しいクリップをお気に入りしてから古いクリップをお気に入りすると、新しいクリップがクリップページのお気に入りタブに表示されないことがある。
📝 Steps to Reproduce
- クリップAを作成する
- クリップBを作成する
- クリップBをお気に入りする
- クリップAをお気に入りする
clips/my-favoritesを{"limit": 1}で呼び出すとクリップAが返されるclips/my-favoritesを{"untilId": "<クリップAのid>"}で呼び出すとレスポンスにクリップBが含まれない
💻 Frontend Environment
* Misskey: 2025.11.1-alpha.1
🛰 Backend Environment (for server admin)
Do you want to address this bug yourself?
- [ ] Yes, I will patch the bug myself and send a pull request
この問題の原因は、フロントエンドがページネーション用のIDとしてクリップID(Clip.id)を渡している一方、バックエンドはお気に入り登録のID(ClipFavorite.id)でページネーションを行う設計になっているためです。
そのため、クリップのお気に入り順がクリップ作成順と異なる場合、正しくページネーションできず、クリップが抜けたり重複したりします。
現状、フロントエンドのPaginator(MkPagination)はAPIレスポンスの各アイテムのid(=クリップID)しか扱えず、お気に入りIDを取得・利用する仕組みがありません。
バックエンドは #16835 でお気に入りIDによるページネーションに対応しましたが、フロントエンドがそのIDを使えないため根本的な解決には至っていません
(参考: backend実装,
Paginator実装)。
現時点でフロントエンド側でお気に入りIDを取得・利用するワークアラウンドや修正は実装されていません。
根本的な解決には、
- APIレスポンスでClipFavoriteのIDも返すようにする
- フロントエンドのPaginatorでID種別を選択できるようにする
などの対応が必要です。
この問題は #12175 のチャンネルフォローID問題と同じ構造です。
今後の修正方針としては、フロントエンドとバックエンドでページネーションに使うIDの整合性を取る必要があります。
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
発生している現象としては #12175 と同じで、同じ対処をしたら直る…のは間違いなさそうです。
ただ、今回は前提が少し異なります。 #12175 は互換性のために既存処理の挙動を変えましたが、#16835 は未リリースバージョンに実装された拡張なため。
よって、今回はv2 APIの新設が妥当だと考えますが、いかがでしょうか…(v2は #12175 でも案の一つとして挙がっていました)
#16835 のrevert(仕方なし…) -> v2の実装 -> フロントエンド側の向き先をv2に -> v1のdescriptionあたりで非推奨なことを明記 のような作業内容になる想定です。
@syuilo どうでしょ
YOSASOU