"The scheduled date must be in the future" の翻訳悩んでいるけど、不親切な状態だなーと思う。サーバーの現在時刻 + 5 分だけど、それが書かれていない。
@mayaeh しかも時刻をあとから変更する時だけチェックして投稿時にはチェックされないよねそれ。不便だわー
@tateisu なんと…
@mayaeh @tateisu 予約のつもりで投稿してるなら、いっそエラーにしちゃった方がいいんじゃないかなぁ。単なる指定ミスかもしれないから、確定して見えてしまうと困るかも。
@noellabo @mayaeh 完全に同意。エラーにしてほしい…。
あと「５分きっかりで本当に大丈夫なの？sidekiqへの投入タイミングが5分なら、エラー判定は少しマージンをもたせるべきじゃないの？」というのもあります
@tateisu @mayaeh 5分自体がマージンなので、本当は残り1分で投入しても支障ないんじゃないかな。
sidekiqに載せると指定時間ぴったりが狙えるけど、最初から載せっぱなしにしとくと負荷が高いから、5分切るまでは投入しない、という処理かと。
@noellabo @mayaeh sidekiq投入インターバルは5分のまま変えないとして- エラーチェックした時点できっちり5分未来が指定されていた- ところがほぼ同時にsidekiqへの投入が走っていて、その投稿がDBに記録されたころには既に終わっていた。- 次の投入タイミング(5分後)にsidekiqに乗り、結果として5分より少し後に投稿される
…くらいは発生しそうだけど、まあどの程度の精度を求めるかによるかなあ…。所詮sidekiqだしキューが詰まってたらダメだし
@tateisu @mayaeh なんか、scheduled_statuses_schedulerのインターバルを'4m'ぐらいにしちゃうのが簡単かもしれませんね……。チェックするの、そんなに負荷の高い処理じゃないし。
@noellabo @mayaeh インターバルって「１日に予約投稿DBをスキャンする回数」なので、そっちを変える方向にいくのは負荷的な影響があると思います…。
@tateisu @mayaeh Mastodon側は何も変更せずに、
5分ギリギリを狙うのはやめた方がいいよ、ってUI上で説明するとか、勝手にマージンとって、10分未満を指定できないように実装しちゃうとか。10分未満はダメって方式なら、サーバの時計のずれとかも吸収できる。6分でもいいか。
@noellabo @mayaeh - 投稿時の予定日時のチェックはサーバ側で行うべき- 指定可能な日時の下限はタンス側の現在＋6分とかにするべき- APIエラー文言も直す…というのが妥当だと思います。
クライアント側は肝心の数字を持ってないので、そっちでがんばるとカスタマイズされたタンスに対応できなくなるのです。
@tateisu @noellabo そのインスタンスが何分以降なら受け付けるのか、数字欲しいですよね。あと予約できる上限の数字も stats とかで取れた方が良さそう？
@mayaeh @noellabo マストドン公式は「カスタマイズされたタンス」に冷たいので、そういうのを追加するなら誰かがフォーク上で用意して各クライアントに対応を求めるという形になるかと思います
@mayaeh @noellabo 前例としては max_toot_chars が存在します。これは公式には存在しませんが、いくつかのクライアントは対応しています。
DTP-Mstdn.jpは、DTP・デザイン・印刷に関わる人々のためのMastodonインスタンスです。特定分野の専門インスタンスですので、日々のつぶやき、耳寄りな情報の共有、ディスカッション、質問とその回答、役立つスクリプトなど、他では投稿しづらい内容も、思う存分トゥートしましょう！
DTP鯖管
@noellabo @mayaeh sidekiq投入インターバルは5分のまま変えないとして
- エラーチェックした時点できっちり5分未来が指定されていた
- ところがほぼ同時にsidekiqへの投入が走っていて、その投稿がDBに記録されたころには既に終わっていた。
- 次の投入タイミング(5分後)にsidekiqに乗り、結果として5分より少し後に投稿される
…くらいは発生しそうだけど、まあどの程度の精度を求めるかによるかなあ…。所詮sidekiqだしキューが詰まってたらダメだし