Misskey: 通知などのページネーションAPIを利用すると未読のものが既読になる場合がある

[syuilo]

💡 Summary

現在のページネーションの仕組みでは、例えば10件表示したい場合は最大11件取得し、0~10件返ってきた場合は「もっと読み込む」が不可能と判断し返ってきたものすべて表示し、11件返ってくれば「もっと読み込む」が可能だと判断して最後の1件は切り捨て、10件だけ表示する仕組み
ここで、通知取得API側からするとAPIによって取得された通知はすべて既読にするので、11件取得されたとき、実際には最後の1件は切り捨てられユーザーの目には入らないとしても、すべて既読扱いになってしまう。

[syuilo]

解決策1:
通知APIなどに、最後の1件は既読にしないようにするオプションを実装する

解決策2:
通知APIなどは取得されても既読にする処理を行わず、別途既読にするAPIを作り必要に応じてクライアントがそこにリクエストするようにする

解決策3:
別のページネーションの仕組みを作る(破壊的なので厳しい)

解決策4;
GraphQLを実装する(難しい)

[tamaina]

別のページネーションの仕組みを作る(破壊的

確かに破壊的だけど、前/次の情報をAPIに足すだけってなら何かを削除するわけではないのでほかのクライアントに影響はない気がする

[syuilo]

足すだけでも変な情報が混じることになるからまずそう
オブジェクトに新しいプロパティが追加されるということならば問題ないけど、通知APIとかは配列で返ってくるので足す余地がない

[mei23]

APIにprev/nextを足すだけだと

クライアントはnextが返ってこなかった場合に

1. サーバーがnextに未対応だからnextが返らない
2. 続きがないからnextが返らない

を区別できない気がする

[rinsuki]

X-Misskey-API-Paging-Info: {"prev": 123, "next": null}

// えー

[tamaina]

通知APIとかは配列で返ってくる

破壊的だったわ

X-Misskey-API-Paging-Info: {"prev": 123, "next": null}

これは良い解決策
APIドキュメントには反映されないので説明に書いておく必要はありそう

[mei23]

prev/next APIを追加する方法では
3rdパーティークライアントにとっては
事前にそのサーバーがprev/nextに対応してるかわからないのでなんからの方法で知る必要がでてくる上に、そもそも旧クライアントが+1件でリクエストし続けるので解決したい問題が解決しないです。

[tamaina]

事前にそのサーバーがprev/nextに対応してるかわからない

X-Misskey-API-Paging-Infoの存在やMisskeyのバージョンで判断して凌いでもらえば……

3rdパーティの旧クライアントを考えればしゅいろの提案で言えば解決策1？そうだとしてもデフォルトで末尾を既読マークしないみたいな動作になってbadだと思う……

[syuilo]

既にMisskeyのバージョンによって処理を変えているクライアントはあるので、同じようにやっていただければ問題ないと思います。
対応できないクライアントがあったとしても実装しないよりはマシなのでrinsuki氏の案が無難に思います。
ただ現在の実装だとレスポンスbody以外に何らかの情報があることは想定されていないので、サーバー/クライアントともにちょっと実装が面倒そうではある

[syuilo]

う～む

[rinsuki]

まあ major version up なら v12 のタイミングで壊したほうが無難感はある