[BUG] Durable Objects alarm not firing due to stale past alarms remaining in storage

[horai93]

Describe the bug

When a Durable Objects alarm fails to fire (e.g., missing CACHE_PURGE_ZONE_ID/CACHE_PURGE_API_TOKEN, error in alarm handler, infrastructure issue), the past alarm timestamp remains in storage indefinitely. This causes subsequent purgeCacheByTags() calls to skip setting a new alarm, resulting in cache purge operations silently failing.

The current implementation doesn't check if an alarm is in the past:

opennextjs-cloudflare/packages/cloudflare/src/api/durable-objects/bucket-cache-purge.ts

Lines 39 to 43 in b60b670

	const nextAlarm = await this.ctx.storage.getAlarm();
	if (!nextAlarm) {
	// Set an alarm to trigger the cache purge
	this.ctx.storage.setAlarm(Date.now() + this.bufferTimeInSeconds * 1000);
	}

If nextAlarm is a past timestamp, no new alarm is set, creating a deadlock where alarm() never fires and tags accumulate in the database.

Steps to reproduce

1. Cause alarm to fail for any reason (e.g., error in alarm() method, possibly missing CACHE_PURGE_ZONE_ID/CACHE_PURGE_API_TOKEN)
2. Call revalidateTag() which triggers purgeCacheByTags() - alarm is set
3. Wait for alarm to fail
4. Call revalidateTag() again - getAlarm() returns past timestamp, no new alarm is set
5. alarm() is never called

Expected behavior

When revalidateTag() is called after a previous alarm has failed:

• The stale past alarm should be detected and cleared
• A new alarm should be set for the future

@opennextjs/cloudflare version

1.9.1

Wrangler version

4.40.2

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T8132
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.13.1
  npm: 10.9.2
  Yarn: 1.22.22
  pnpm: 9.14.2
Relevant Packages:
  next: 15.5.4 // Latest available version is detected (15.5.4).
  eslint-config-next: 15.5.4
  react: 19.1.1
  react-dom: 19.1.1
  typescript: 5.6.3
Next.js Config:
  output: standalone

Additional context

No response

[vicb]

Thanks for the issue

Can you expand on the actual scenario that is causing errors for you?

i.e. if "possibly missing CACHE_PURGE_ZONE_ID/CACHE_PURGE_API_TOKEN" then there is no way we can purge the cache regardless how often we retry.

Alarms have a built-in retry mechanism so I'm only trying to better understand what we should change here.

[horai93]

@vicb
Thank you for taking the time to review this issue.
Let me explain our situation.

First, we initially deployed without defining the required environment variables (CACHE_PURGE_ZONE_ID and CACHE_PURGE_API_TOKEN for purging). Then, presumably because the
environment variables were missing, the alarm failed, likely within internalPurgeCacheByTags inside the alarm() method.

After that, we added the environment variables, but at the stage of purgeCacheByTags executed by revalidateTag, the past alarm continues to remain in const nextAlarm = await this.ctx.storage.getAlarm();.

As a result, it seems that unless we somehow modify the Durable Object state (such as deleting the Durable Object once and redeploying), even if we set the environment variables
correctly, the alarm will no longer fire.

In fact, when we directly modified the Durable Object code in our staging environment to verify, the alarm retrieved by getAlarm() was from 8 days ago.

In other words, the issue is that once it fails, we fall into a state where we cannot clear the Durable Object's alarm, and we're wondering if there's any way to resolve this.

[vicb]

@horai93 thanks for adding details. It will help updating the code in the open next adapter and I'll get in touch with the internal teams at Cloudflare to see how we can improve the DO DX in general!

[vicb]

internal thread about this issue