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

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

@ars42525 こんな感じ。

"POST /api/v2/media HTTP/2.0" 202 349 "-" "Tusky/17.0 Android/10 OkHttp/4.9.3"

"POST /api/v1/statuses HTTP/2.0" 422 105 "-" "Tusky/17.0 Android/10 OkHttp/4.9.3"

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

@ars42525 せんきゅー。

ところでひょっとしてこの手順、いまだに公式ドキュメントないって奴？？

@noellabo そもそもapi/v2/mediaがドキュメントになくない？(マジ？w)

@ars42525 たぶんみんなWebUIのソースコード読んで実装してるよ……。

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

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

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

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

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

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

@ars42525 @noellabo FYI https://github.com/tateisu/SubwayTooter/blob/18a638433c2bab61d946eee4496587dac9fabf1d/app/src/main/java/jp/juggler/subwaytooter/util/AttachmentUploader.kt#L406