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

🤔

いま次は2.0だーってどでかいのが入る感じのふしあるけど別に2.0がでたからといってその後は小さい変更しか入らないかというとたぶんそうでもない🤔😇

Redisで同じキーの場合の値の辞書順ソートは…頼っていいものかとか結局数値順でないから事故るなーとかそんなつよい値入れてちゃんと動くのとか考えた結果忘れてた

@Gargron @unarist @aschmitz (I was thinking we will give up under msec ordering and pray toot won't happen within msec. )

@unarist @Gargron Note: Remember that Home TL ordering redis keys are treated as double and only have 53bit precision and msec timestamp is already 41 bit length and Snowflake id will be 57bit now. So, last 4 bit on Snowflake id is ignored on redis Home TL sorting key.

New snowflake id Mastodon implement can be used until "10889-08-02 05:31:50 UTC".
I think it's long enough period for mortal human.

1ms以内にtootが複数発生はさすがにしないでしょっていう甘い考え方をしている🤔

なんかとりあえずうまく伝わったぽい

@unarist @Gargron Yes, that's what I suggest! thx!

@unarist @Gargron I think really big delay isn't caused by Sidekiq delay and it's caused by other functions (fetching boosted original status, search toot url, etc). I suggest arrival numbering for simple toot delivery.(Sidekiq delay is not big because it will retry only 3 times(OStatus) and 8 times(ActivityPub))

そのまま来たらggteaではパッチ当てるだろうなーという程度にはbreaking😇

@unarist ぁっ…😇

問答無用にbackfillする場合の問題投げたよ🙃

@mayaeh きっちり現在時点で既に53bit超えてます

@mayaeh だめだとおもうー

なんかてーぶるに対する共通処理でごにょってる感あるので不安が大きい

@unarist コード読まなきゃ…😇

ちなみについったさんのSnowflakeは60年くらいしかもたないと思いますけど、今回実装されたSnowflakeはもっと十分な余裕あります🤔

ねこねこー