Quick reference and self-quiz

A cell is a Durable Object instance: a small server with a name and a private SQLite database. It serves HTTP, holds WebSocket connections, sets alarms, and makes outbound connections. Chapter 2.

One thread per cell means two requests never run at the same instant, but a second request can interleave while the first awaits anything that is not a storage call. Both requests read the same old value and both write value + 1. Fix it by keeping the read-modify-write free of non-storage awaits (storage calls are synchronous and never interleave), or by wrapping the work in blockConcurrencyWhile(). Lab 1, Part 2 shows ten racy increments all returning 1, and the gated version returning 1 through 10. Chapter 2.

No. The output gate holds each write response, and every outbound effect, until a durability proof covers the write. A client cannot see a success for a write that was not made durable. Chapter 4; Chapter 1 § 03.

Two things separate a hibernated cell from a cold one: its hibernatable WebSocket clients stay connected, and it stays on its node. Memory does not survive. The constructor runs again on every wake, including each message to a hibernated room, so restore state from storage inside the handler and keep the constructor trivial. Chapter 2; Lab 3, Part 2.

No, it is opt-in: CELLD_IDLE_EVICT_S sets the idle seconds, and without it only memory pressure or the residency cap removes a resident cell. It matters because balancing moves only hibernated cells, so a fleet without idle eviction balances only the cells that hibernate on their own. Chapters 2 and 5.

A cell (a Durable Object) models an entity: a named unit whose state persists indefinitely. A workflow models a process: steps that start, run, and finish. celld's Workflows are the process primitive built on the entity primitive. Chapter 1 § 06; Chapter 7.

One node: a bucket proof, one storage round trip to the bucket. Two or more nodes: a fleet proof, which answers once every follower has fsynced the write; the bucket upload finishes afterwards. Chapter 3.

It requests the fleet posture and does not get it: the node falls back to bucket proof, because a fleet proof needs at least two nodes. Chapter 3.

With a conditional write to the cell's ownership record in the bucket: create when no record exists, compare-and-swap when one does. The bucket accepts only one such write. Every activation advances the epoch, a takeover and a local wake alike, and the cell's data is written under that epoch's prefix. Chapter 4.

After a bucket proof, celld re-reads the ownership record and acknowledges only if it still names this node at this epoch. Reading the record means a paused process or a skewed clock cannot pass the check; a clock comparison could be fooled by either. Chapter 4.

It fences itself. When its published lease expiry passes, it stops each active cell, fails incomplete requests, logs a line starting SELF-FENCE:, and exits with code 3, so it cannot keep serving state it can no longer prove. Chapter 4.

Fleet-qualified: Amazon S3, Cloudflare R2, Google Cloud Storage, Tigris, and Azure Blob Storage. MinIO passes the test but is not qualified; Backblaze B2, Hetzner, and DigitalOcean Spaces are not. The startup probe runs conditional writes that must succeed and fail in the right places, plus a ranged read that must return exactly the requested bytes. A clear contract violation stops the node; an ambiguous failure gets three attempts and then a warning. Chapter 3.

No. The startup probe cannot be disabled: CELLD_STORAGE_PROBE is on the rejected list, and a node with it set does not start. celld diagnose --read-only skips the probe only for that on-demand check. Chapters 3 and 5.

Deployments (with container images), cell state, ownership records, node leases, the shared peer-authentication secret, the fleet capacity sample, alarm wake entries, large KV values, and all R2 objects. Whoever holds the bucket credentials controls the fleet. Chapters 3 and 8.

Only hibernated cells move. A node's target is the fleet's owned cells divided by weight, where CELLD_PLACEMENT_WEIGHT defaults to the CPU count. POST /rebalance/pause and /resume on any internal listener govern the whole fleet. Chapter 5.

Under fleet durability, as a full stop: stop every v0.5.1 node, then start the v0.6.0 nodes, because a v0.6.0 node needs a follower that speaks the ranged CLT2 log-tail format and refuses to start in a mixed fleet. A fleet on CELLD_DURABILITY=bucket has no followers and can roll. Chapter 5.

Never by starting an old binary against the upgraded bucket. The only rollback is the backup taken while the fleet was stopped, and it loses every write made after it. Chapter 5.

No. cacheTtl has no effect and cacheStatus is null: KV on celld is a durable store with KV's API, not a CDN. Reads route to the namespace's cell. Chapter 6; Lab 2, Part 2.

celld deletes the message. Between attempts, a retried message becomes visible again after the delaySeconds passed to retry() or retryAll(), or the consumer's retry_delay by default; celld adds no exponential backoff, so an application that wants one computes it from message.attempts. Chapter 6; Chapter 9, Step 05.

The script fails to load and the node goes down: Lab 2, Part 5 shows the local node exiting with queue consumer has no queue handler. Declare a consumer only in a script that exports queue(). Chapter 6.

On a store that reports no version of its own, the ETag becomes the version, so identical content produces the same version. celld dev's local store instead numbers each write from a store-wide counter, so identical bytes get different versions there (Lab 2, Part 4 showed 74 and 75). Either way, never use a version to count writes, and use checksums.md5 as the content hash. Chapter 6; Chapter 9, Step 07.

Through a Worker. celld serves a bucket through the binding only: there is no public bucket URL, no presigned URL, and no S3 endpoint into an R2 binding. Chapter 6; Chapter 9, Step 07.

Each facet lives in its own SQLite file with its own replication stream, so a facet write commits in the facet's database. Rolling back a root transaction does not undo a facet call made inside it. State that needs one atomic commit belongs in one database. This changed in v0.6.0. Chapter 6; Appendix C.

The same mechanism. run() executes again from the top, completed steps return their stored results, and everything outside a step runs again. After a durable sleep nothing failed, but the re-execution is identical: Lab 3, Part 3 counted the top of run() running twice across one sleep while each step ran once. Chapter 6; Chapter 9, Step 06.

Sunday. Day-of-week 1 is Sunday, as on Cloudflare and opposite to most cron dialects. Cron runs in UTC at one-minute resolution, exactly once per occurrence fleet-wide. Chapter 6.

No. A celld dev deploy does not apply migrations, and celld d1 migrations apply needs a fleet. Locally, run the SQL from the Worker (for example CREATE TABLE IF NOT EXISTS), as celld's own examples/d1 does. Chapter 9, Step 07; Lab 2, Part 3.