神楽坂しえる @Clworld@md.ggtea.org

ActivityPub対応を直前に控えてmasterは不安定な状態になっていますか🤔

Debianパッケージ欲しいのissueです。放置です。誰かが本気出してパッケージ作ればパッケージが出来るんじゃないですかね☺️🙃 https://github.com/tootsuite/mastodon/issues/3576

Boostしたら画像unknownなのがhome TLに出るのは理解できるけどBoostじゃない場合は理解できない😴

Debianパッケージ欲しいけどDebianのパッケージ本体のだと基本的に枯れてる感じに熟成されるので1.3から更新されないみたいな状況が発生しそう

pixivさん設営日を1日目とカウントしているのか(？？)

transactionが外れたことで:
まずLTL/FTLでREST APIを使った場合にstatusだけ作成されたmedia取得に失敗しているtootが見える可能性があるのがまず一つ。(homeとstreamingはRedisにidが送られないので出ない)
Boostの場合でBoost元のstatus作成時にmedia取得に失敗してstatusだけが作成されると、再実行時にboost元statusは既にあると判定されて Boostの作成は正常終了するのでhome/streamingも全部でunknownになる予感がする。

良く分からなくなったけど transaction が入る -> reblogの作成が先になる -> akiさんのリファクタが入ってtransactionが外れる の順か

@unarist そうっぽい(reblogを最初に作るから大丈夫っぽい)

IPv4インスタンスでさっきBoostされたTootが流れてこないのでこっちの事象は問題ないのか…？

aki さんー ひっそりと ApplicationRecord.transaction をなくしてたのやめてくだされー😅 https://github.com/tootsuite/mastodon/pull/4164/files#diff-46fa9315afa60bc412907fc380d61977L57

ProcessFeedServiceがリファクタされた結果読む時にクラスをたらい回しにされてる
After ProcessFeedService is refactored, I'm sent around many classes when I read ProcessFeedService...

@unarist 前にこのせいで私がIPv6onlyインスタンスのtootをBoostすると私の発言としてIPv6非対応インスタンスに飛んでいくって問題が発生していたはず。

@unarist そうじゃないんです。一旦statusが作成された後の処理が失敗した時にrollbackされて元のstatusが削除されないと再実行された時にこのstatusは既に存在するのでokって判定になってDBから取ってくるだけで処理が成功してしまうのです。

@unarist transaction無いと致命的に駄目じゃないです？駄目なのを直すためにtransaction入れたんですし。

@unarist 😴💤

@unarist 私の認識だとそう…🤔 今深く考えると寝れなくなりそうなのでねる…

@unarist streamingの方は画像取得まで行われた後にpush処理のsidekiqが呼ばれるから大丈夫な認識🤔(media_attachmentは)
RESTはstatusレコードが出来ると読み込まれてしまうけど前にtransactionが入ってるしなんとかなりそうな気もする…🤔？？？

@unarist REST API ?🤔

@Clworld When toot is on WebUI, it must be anything is ready(except OpenGraph). So, transcoding image task cannot be delayed... and transcoding task is called synchronously from various workers.