sync-data-stuck
一次対応
agg.org / agg.app_user / agg.org_membership / agg.invitation の sync_error を読む。JobRunr で reconcile-data-to-workos が動いているか、失敗した sync-data-to-workos ジョブが残っていないか、agg.workos.apiKey と agg.workos.enabled が入っているかを確認
custom_details.tables にテーブルごとの pending / failed / oldest_pending_seconds が入っている。読む順は failed が先で、両者は別の障害を指す。
failed > 0 — その行は一度以上 push されて WorkOS に拒否されている。push は成功時に sync_error を消すので、残っているものは再試行しても同じ本文で拒否され続ける。閾値なしで発報するのはこのため。何を拒否されたかは行に書いてある。
SELECT id, updated_at, synced_at, sync_error FROM agg.org WHERE sync_error IS NOT NULL;-- agg.app_user / agg.org_membership / agg.invitation も同じ形failed = 0 で oldest_pending_seconds だけ伸びている — 押し出しそのものが止まっている。行を書いた側が sync-data-to-workos を enqueue するのが通常経路で、そこが落ちた行は毎時の reconcile-data-to-workos が拾う。つまり最大 1 時間は自力で復旧する余地があり、閾値 15 分はその途中で鳴る。JobRunr ダッシュボードで見るのは 3 つ。
reconcile-data-to-workosが recurring job として動いているか（0 * * * *、paused でないか）sync-data-to-workosの失敗ジョブが溜まっていないか- どちらも動いていて pending が減らないなら
agg.workos.enabledとagg.workos.apiKey（未設定なら push は即 return する）
pending の数そのものは判断材料にならない。reconcile は 1 テーブル 1 回あたり agg.workos.maxRowsPerRun（200）行までしか出さないので、招待の一括投入は数時間かけて正常に捌ける。伸び続ける oldest_pending_seconds だけが異常のしるし。
拒否された行は本文を直すのが復旧で、再試行ではない。sync_error が指す項目を管理画面から修正すると updated_at が動き、次の push 対象に戻る。
押し出しが止まっていた場合は原因を取り除いたうえで、JobRunr から reconcile-data-to-workos を手動実行すれば待たずに流れる。個別の行だけを急ぐなら sync-data-to-workos を (resource, id) 指定で再実行する。
メンバー画面の 未同期 / 同期済 / 失敗 バッジは同じ列を見ているので、復旧の確認はその画面でもよい。
エスカレーション
Section titled “エスカレーション”WorkOS 側が受け付けない（API が 4xx を返し続ける、ロールが workspace に存在しない）ところまで切り分けたら、WorkOS のダッシュボードを触れる担当に渡す。権限変更が反映されていない状態が続くので、緊急なら該当ユーザーの操作を止める判断を先に取る。
まだない。