1Password Connect OperatorがAPIレート制限に刺さったのでpollingをやめた話

原因はoperatorのクラッシュではなく、1Password側のAPIレート制限だった

Podはクラッシュせず、Secretが更新されないままHelmアップグレードが`pending-upgrade`で止まる間接的な壊れ方

デフォルト10分間隔×対象6件の単純計算でも864リクエスト/日で日次上限（1,000）に迫っていた

実際は1件のポーリングで複数回のAPI呼び出しが発生しうるため、見積もりよりさらに早く上限へ達していた

operatorは起動時に管理下の全件をreconcileする挙動を持つ

`pollingInterval`を実質無効化（約10年）まで伸ばし、通常時はpollingに頼らない運用へ

Terraformの`yamlencode()は大きな整数を科学的記数法（`3.1536e+08）でYAML化してしまう

operator側はパースできず黙って600秒にフォールバック。`terraform plan`は差分なしに見えるため気づきにくい

`tostring()`で明示的に文字列化して回避

完全restart-onlyは手動運用の負荷が大きく、安全余裕とのバランスで1日間隔に落ち着けた

最終的にはこのoperatorを使う側のアプリCIへ管理主体を移動。`terraform state rm`で既存リソースを壊さず管理だけ付け替えた

pollingの見積もりは下限に過ぎないと踏まえて実測で確認する

`yamlencode()`の科学的記数法化に注意する

共有インフラは使う側のリポジトリへ寄せると`terraform state rm`で安全に移管できる