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

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.

Wish: delayed paperclip transcode😩

@Naf なるほどー
fnyaがディスク使用3.5Gなのでsetup時に最小限にしたのは多少効果があるっぽくて嬉しい。メモリはもう少し動いた後の状態で聞いた方が良かった予感…🤔 64bitです？

@Naf free -m と df -lh どのくらいです？(個人的興味😅 )

@unarist メモリを大量に使うバグがあるとかないとか直ったとかなんかいろいろ見つかって分からない(…😑 )