<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>durable-objects on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/tags/durable-objects/</link><description>Recent content in durable-objects on Ikoma's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 24 Sep 2026 21:33:45 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/tags/durable-objects/index.xml" rel="self" type="application/rss+xml"/><item><title>A Durable Object Alarm Retries 6 Times, Then Stops</title><link>https://blog.yusukeikoma.com/posts/durable-object-alarm-retries-six-times-then-stops/</link><pubDate>Thu, 24 Sep 2026 21:33:45 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/durable-object-alarm-retries-six-times-then-stops/</guid><description>A Durable Object has one alarm, runs it at least once, and retries a failing handler with backoff up to six times. After that nothing wakes the object again. A walkthrough of a lease-expiry ledger that survives all three: a table as the source of truth, a constructor that re-arms the alarm, and an effect that tolerates being run twice. Run on local workerd, with the documented limits quoted from Cloudflare.</description></item><item><title>Durable Object Hibernation Keeps the WebSocket and Drops Every Class Field</title><link>https://blog.yusukeikoma.com/posts/durable-objects-websocket-hibernation/</link><pubDate>Tue, 22 Sep 2026 13:39:45 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/durable-objects-websocket-hibernation/</guid><description>Cloudflare&amp;rsquo;s docs say hibernation keeps WebSocket connections open and discards in-memory state. This post runs a small Durable Object under local workerd and watches exactly what that means: the socket stays OPEN, the constructor runs again on the next message, class fields reset, attachments survive only if you serialize them, and a pending timer or the standard WebSocket API quietly turns hibernation off. Production behaviour and billing are not tested.</description></item><item><title>Batching and Bounded Frames on a Metered Relay</title><link>https://blog.yusukeikoma.com/posts/batching-and-bounded-frames-on-a-metered-relay/</link><pubDate>Wed, 19 Aug 2026 12:47:53 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/batching-and-bounded-frames-on-a-metered-relay/</guid><description>When every WebSocket message costs money and every frame has a hard cap, you need batching with independent flush triggers, a single-frame threshold below the cap, bounded chunking, and capability flags that survive mixed-version rollouts. The sharp edges are ordering on shutdown and a zero value that disappears from the wire.</description></item></channel></rss>