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

このGGTeaが1.5.1、ねこはうすも1.5.1なんですけど、mdxは問題の1コミット前で止まってて神ががってる。

ねこはうすはねこはうすって名前があって分かりやすいので名前は重要だねーって思いはじめた🤔😺

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が入ってるしなんとかなりそうな気もする…🤔？？？