# CF Worker Durable Object `setAlarm` Timestamp Bug

## Critical Pitfall

Cloudflare Workers Durable Object `this.storage.setAlarm()` takes a **timestamp** (milliseconds since epoch), NOT a **duration** (milliseconds from now).

```typescript
// ❌ BROKEN — alarm fires immediately (900000ms since epoch = 1970-01-01, already expired)
await this.storage.setAlarm(SESSION_TTL_MS);

// ✅ CORRECT — alarm fires after the duration
await this.storage.setAlarm(Date.now() + SESSION_TTL_MS);
```

## Symptoms
- Sessions created with status "pending"/"active" → return "cancelled" on immediate next poll
- DO alarm handler fires within seconds of creation
- All auth/addon-url sessions appear broken with no obvious error

## Diagnosis
Check the alarm handler in the DO's `alarm()` method — if it cancels pending/active sessions, and sessions are being cancelled immediately, `setAlarm` is firing too early.

## Affected Code
Every call to `this.storage.setAlarm()` in the DO class must pass `Date.now() + DURATION_MS`, not just `DURATION_MS`.

## Discovery
Found 2026-05-31 debugging Unspooled QR auth flow. All debrid auth and addon URL sessions were immediately cancelled. Traced through DO code to find `setAlarm(SESSION_TTL_MS)` (900000) being interpreted as an epoch timestamp from 1970.