@ars42525 Tuskyの投稿添付画像アップロードって、POST /api/v2/mediaしたあとに、/api/v1/mediaをポーリングしないでPOST /api/v1/statusesしてる?

POST v2/media --> 200
POST v1/statuses

ってパターンかな。

202返ってきてこうなると思うんだけど……(WebUI)

POST v2/media --> 202

GET v1/media --> 206
(wait 1000ms)

GET v1/media --> 206
(wait 1000ms)

GET v1/media --> 200
POST v1/statuses

Yuito使ってると200以外のステータスコードはprintしてるのでわかるんですが(もしかしたらDebugだけかも?)206が帰ってくるリクエストはないのでポーリングしてないと思います
処理前の画像添付するとエラーになります?

@ars42525 投稿を作成する処理時点で完了していなかったら、バリデーションエラーになるようになっているので、POST /api/v1/statusesが422を返してくるんじゃないかと思います。

バニラ鯖なんだけど、そういうログがでてるんですよね。

とりあえず投稿には成功してほしいところではあるけど、非同期処理の設計難しいね
とりあえずIssueは上げときます、余裕あったら直すかな

投稿を他のサーバに伝達する時点で添付メディアがまだない、となると非常に大変なことになのです。影響がMastodonだけに収まらなくなってしまいます。

フォロー

@tateisu @ars42525 それもそうだ。配送しちゃうもんな……。

投稿APIも202を返す未来(クライアント開発各位が大泣きしそう)

添付メディアの投稿が非同期になった趣旨はpumaのスレッドを長時間占拠しないこと、HTTPの経路(nginxやプロキシなど)で打ち切られる問題の対策、なのです。APや投稿API自体まで非同期にする理由はありません。クライアントが添付メディアの完了をきちんと待てばそれですむ話です。

ST的には待機部分はコルーチン上で普通にwhileループ回してますね。言語レベルで非同期待機できるkotlinえらい

別にメディア投稿を非同期にしたかったわけではないのか、じゃあ同期処理として扱うのも自然だ
Tuskyもメディア投稿のAPI叩くCoroutineを待機処理含むCoroutineに置換するだけで解決しそう、Kotlinえらい

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。