https://blog.yusukeikoma.com/ja/tags/cloudflare/Recent content in cloudflare on Ikoma's BlogHugoja-jpThu, 24 Sep 2026 21:33:45 +0900https://blog.yusukeikoma.com/ja/posts/durable-object-alarm-retries-six-times-then-stops/Thu, 24 Sep 2026 21:33:45 +0900https://blog.yusukeikoma.com/ja/posts/durable-object-alarm-retries-six-times-then-stops/Durable Object のアラームは1つだけで、少なくとも1回実行され、失敗するハンドラーはバックオフ付きで最大6回再試行されます。それが尽きると、オブジェクトを再び起こすものは何もありません。この3つに耐えるリース失効の台帳を、コードに注釈をつけて見ていきます。真実を持つ表、アラームを再設定するコンストラクター、2回実行されても困らない副作用です。ローカルの workerd で動かし、制限は Cloudflare の文書から引用しています。https://blog.yusukeikoma.com/ja/posts/durable-objects-websocket-hibernation/Tue, 22 Sep 2026 13:39:45 +0900https://blog.yusukeikoma.com/ja/posts/durable-objects-websocket-hibernation/CloudflareのドキュメントはWebSocket Hibernationについて、接続は維持され、メモリ上の状態は破棄される、と書いています。この記事では小さなDurable Objectをローカルのworkerdで動かし、それが具体的に何を意味するかを観察します。ソケットはOPENのまま、次のメッセージでコンストラクターが再実行され、クラスのフィールドは初期化され、アタッチメントはserializeしたものだけが残り、保留中のタイマーや標準のWebSocket APIを使うとハイバネーションがひそかに無効になります。本番の挙動や課金は試していません。https://blog.yusukeikoma.com/ja/posts/batching-and-bounded-frames-on-a-metered-relay/Wed, 19 Aug 2026 12:47:53 +0900https://blog.yusukeikoma.com/ja/posts/batching-and-bounded-frames-on-a-metered-relay/WebSocket のメッセージごとに課金され、フレームにも上限がある環境では、独立したフラッシュ条件を持つバッチ送信、上限より低い単一フレームのしきい値、上限付きの分割、混在バージョンのロールアウトを生き延びる能力フラグが必要です。難所は、終了時の順序と、ワイヤ上から消えるゼロ値です。