{"_self":{"principle":"Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.","widget":"article_topology","feature":"topology","name":"Article topology","what":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","contains":"claims, sources, anecdotes, question_graph slice","slug":"cloudflare-os-async","urls":{"read":"https://miscsubjects.com/api/articles/cloudflare-os-async/topology"},"how_to_use":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","write":null,"imessage":null,"router_tag":null,"proof_chain":[{"step":1,"claim":"Articles are voxel graphs of tiered claims, not prose blobs.","verify":"https://miscsubjects.com/api/articles/constitution"},{"step":2,"claim":"Claims link to hash-chained sources via source_ids.","verify":"https://miscsubjects.com/api/articles/cloudflare-os-async/sources"},{"step":3,"claim":"Ask reads topology; ingest/claim append to ledger.","verify":"https://miscsubjects.com/api/protocol"},{"step":4,"claim":"Models queue growth: populate → collaborate → repair → reflex.","verify":"https://miscsubjects.com/api/protocol/grow"},{"step":5,"claim":"Graph proves its own shape (reflex) and $/claim (yield).","verify":"https://miscsubjects.com/graph.html?layer=reflex"},{"step":6,"claim":"Full feature index + _explain on every API response.","verify":"https://miscsubjects.com/api/articles/system-map"}],"related_features":[{"id":"ask","name":"Ask protocol","what":"Answer only from topology; creates question_node with gaps and ingest_hint.","urls":{"read":"https://miscsubjects.com/api/articles/cloudflare-os-async/prompts","write":"https://miscsubjects.com/api/protocol/ask"}},{"id":"graph_topology","name":"Cross-article graph","what":"Merged claims/sources across condition+stack slugs for one question.","urls":{"read":"https://miscsubjects.com/api/articles/cloudflare-os-async/graph-topology?question=..."}},{"id":"question_graph","name":"Question graph","what":"Ask nodes (questions + gaps) and evidence_ingest nodes (pasted model output).","urls":{"read":"https://miscsubjects.com/api/articles/cloudflare-os-async/question-graph","write":"https://miscsubjects.com/api/protocol/ask"}},{"id":"voxels","name":"Voxel graph","what":"Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance.","urls":{"read":"https://miscsubjects.com/api/articles/cloudflare-os-async/voxels","write":"https://miscsubjects.com/api/protocol/claim"}}],"system_map":"https://miscsubjects.com/api/articles/system-map","system_map_markdown":"https://miscsubjects.com/api/articles/system-map?format=markdown","not_medical_advice":true},"_explain":{"feature":"topology","name":"Article topology","what":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","why":"Every feature is auditable collective intelligence","how":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","model":null,"verifies":null,"urls":{"read":"https://miscsubjects.com/api/articles/cloudflare-os-async/topology"},"imessage":null,"router":null,"related":[{"id":"ask","what":"Answer only from topology; creates question_node with gaps and ingest_hint."},{"id":"graph_topology","what":"Merged claims/sources across condition+stack slugs for one question."},{"id":"question_graph","what":"Ask nodes (questions + gaps) and evidence_ingest nodes (pasted model output)."},{"id":"voxels","what":"Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance."}],"not_medical_advice":true},"slug":"cloudflare-os-async","title":"waitUntil, Queues, Workflows or Cron: choose by durability","register":"essay","tags":["cloudflare","architecture","queues","cloudflare-os"],"updated_at":"2026-07-26T06:07:46.592Z","body_excerpt":"A request has to return now. The work behind it takes ninety seconds, or ten minutes, or has to happen at 4am whether or not anyone visits. Cloudflare gives you four ways to move that work off the response path, and they are not interchangeable: pick the wrong one and you either lose the job silently, pay for durability you never needed, or discover in production that the thing you tested locally cannot exist there.\n\nThis page settles the choice, gives the working configuration for each, and publishes the measured behaviour of the two that run in this account.\n\n## Evidence status\n\n**Observed** marks first-party measurements or runtime receipts from the named environment.\n**Derived** marks arithmetic calculated from cited inputs. **Specified** marks vendor or standards\ndocumentation. **Implemented** and **deployed** name code and live-state evidence, respectively.\n**Reproduced** means the stated procedure was rerun. **Externally attested** marks operator reports;\nthose reports show that an experience occurred, not that it is universal.\n\n## Four mechanisms, and the one property that decides between them\n\nThe property is **durability** — whether the work survives the death of the invocation that started it. Duration is the second question, not the first.\n\n| | `ctx.waitUntil` | Queue (`queue()` consumer) | Workflow | Cron Trigger |\n| --- | --- | --- | --- | --- |\n| Survives the request's Worker dying | No | Yes — the message is persisted before `send()` resolves | Yes — each completed step is persisted | N/A, nothing starts it but the clock |\n| Retry semantics | None. The promise is cancelled | Whole batch retried; `max_retries` default 3; per-message `ack()` / `retry()` | Per-step; default `limit: 5`, `delay: 10000`, `backoff: \"exponential\"`, `timeout: \"10 minutes\"` | None. A failed tick is a lost tick |\n| Maximum duration | 30 s after the response is sent | 15 minutes wall clock per consumer invocation | Unlimited wall clock per step; `step.sleep` up to 365 days | 15 minutes wall clock |\n| Ordering | N/A | **Not guaranteed** | Guaranteed within one instance — single-threaded | By schedule only |\n| Delivery guarantee | None | At-least-once | At-least-once per step; the step *result* is cached, so a completed step is not re-executed | At-least-once |\n| Observability | Workers Logs only | Queue metrics, DLQ contents, consumer logs | `wrangler workflows instances list/describe`, REST API, dashboard | Past Cron Events (last 100), Workers Logs, GraphQL Analytics API |\n| Cost unit | Nothing beyond the parent request | $0.40 per million operations; one message ≈ 3 operations (write, read, delete) | Requests + CPU ms + GB-month storage + $0.80 per additional 100,000 steps | One Worker request per tick |\n| Redeploy mid-flight | Undocumented; assume the in-flight promise is lost | Unacked messages are redelivered to the new code | Undocumented. The step journal survives, so completed steps are not re-run, but a changed step list is unhandled | Next tick runs the new code |\n\nTwo rows in that table are marked undocumented, and that is a real gap rather than a research failure. Tim, writing at thisisacomputer.com, tried to find the answer for Workflows and reported: \"Making changes to durable workflows is tricky. Cloudflare has no documentation around this. You're on your own, so be careful.\" His own working rules — appending a step at the end is safe, inserting one in the middle is probably not — are inference, and he labels them as inference. Treat them the same way.\n\n## `ctx.waitUntil` buys thirty seconds and no promises\n\n`ctx.waitUntil(promise)` tells the runtime to keep the invocation alive after the response has been sent. It is the third argument to every handler (`fetch(request, env, ctx)`), and it is not storage: nothing is written anywhere, and there is no retry.\n\nThe limit is hard and shared. From the Context API reference: \"For HTTP-triggered Workers, `ctx.waitUntil()` can extend execution for up to 30 seconds after the response i","ranking":"safety-first (interaction_risk/limitations), then quote-gated effective_weight","claims":[{"id":"c13","text":"Queues has no immediate dead-letter operation for a known poison message; operators must ack it, burn retries or write a separate failure queue.","tier":"anecdotal","section":"There is no way to dead-letter a message you already know is poison","interaction_risk":false,"status":"active","source_ids":["p1","s4"],"why_material":"The failure path must be designed explicitly.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.3,"quote_gated":false},{"id":"c14","text":"Public issues report that a queue producer binding breaks all routes under wrangler dev --remote and can conflict with remote-only bindings.","tier":"anecdotal","section":"Declaring a queue producer breaks every route under --remote","interaction_risk":false,"status":"active","source_ids":["p2","p3","s12"],"why_material":"Local success, remote development and production are different test surfaces.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.3,"quote_gated":false},{"id":"c16","text":"One production policy keeps cheap non-critical report generation on Workflows but routes payments to an engine independent of Cloudflare downtime.","tier":"anecdotal","section":"Ship payments somewhere else; keep Workflows for the cheap reports","interaction_risk":false,"status":"active","source_ids":["p5"],"why_material":"It gives a concrete correlated-failure boundary.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.3,"quote_gated":false},{"id":"c17","text":"Workers can be invoked by Cron Triggers, service bindings and Queue consumers rather than only HTTP.","tier":"anecdotal","section":"Cron is the only one that starts itself","interaction_risk":false,"status":"active","source_ids":["p6"],"why_material":"The available trigger surface changes the architecture choice.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.3,"quote_gated":false},{"id":"c1","text":"waitUntil can extend an HTTP invocation for at most 30 seconds after the response, with no persistence or retry.","tier":"fact","section":"ctx.waitUntil buys thirty seconds and no promises","interaction_risk":false,"status":"active","source_ids":["s1"],"why_material":"It is licensed only for work whose loss is harmless.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c2","text":"Cloudflare Queues provides at-least-once rather than exactly-once delivery, so consumers need idempotency keys.","tier":"fact","section":"A queue is the cheapest thing that survives your Worker dying","interaction_risk":false,"status":"active","source_ids":["s2"],"why_material":"Duplicate delivery is part of the contract.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c3","text":"Without per-message acknowledgement, one failed item causes the entire delivered batch to retry.","tier":"fact","section":"A queue is the cheapest thing that survives your Worker dying","interaction_risk":false,"status":"active","source_ids":["s3"],"why_material":"Batch handling determines duplicate side effects.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c4","text":"Queue consumer invocations have a 15-minute wall-clock limit.","tier":"fact","section":"Four mechanisms, and the one property that decides between them","interaction_risk":false,"status":"active","source_ids":["s5"],"why_material":"Longer or multi-stage jobs need another primitive.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c5","text":"A typical Queue delivery is billed as three operations: write, read and delete.","tier":"fact","section":"The bill, per mechanism, with the arithmetic","interaction_risk":false,"status":"active","source_ids":["s6"],"why_material":"It is the basis of the worked Queue cost.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c6","text":"Workflow steps must use deterministic names and idempotent work because the durable result journal keys completed work by step.","tier":"system","section":"Workflows pay for durability one step at a time","interaction_risk":false,"status":"active","source_ids":["s7"],"why_material":"Unstable names defeat durable replay.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c7","text":"Workflow steps default to five retry attempts separated by ten seconds.","tier":"fact","section":"Workflows pay for durability one step at a time","interaction_risk":false,"status":"active","source_ids":["s8"],"why_material":"Default retries can repeat non-idempotent side effects.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c8","text":"Workflows bills requests, CPU, steps and retained state as separate units.","tier":"fact","section":"The bill, per mechanism, with the arithmetic","interaction_risk":false,"status":"active","source_ids":["s9"],"why_material":"Durable execution has a different meter from Queues.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c9","text":"A Wrangler deploy replaces existing Cron Triggers with the configured array, while an empty array removes them.","tier":"fact","section":"Cron is the only one that starts itself","interaction_risk":false,"status":"active","source_ids":["s10"],"why_material":"A configuration edit can silently erase the schedule.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c10","text":"Durable Object alarms provide at-least-once per-entity scheduling with automatic retries when alarm throws.","tier":"fact","section":"Durable Object alarms win when the schedule belongs to one entity","interaction_risk":false,"status":"active","source_ids":["s11"],"why_material":"They are the correct clock when the schedule belongs to one stateful entity.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c11","text":"An independent operator found Workflow redeploy behavior insufficiently documented and treats safe step-list changes as inference.","tier":"independent","section":"Four mechanisms, and the one property that decides between them","interaction_risk":false,"status":"active","source_ids":["s13"],"why_material":"Undocumented mid-flight changes must not be presented as guarantees.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c12","text":"Current Wrangler has a Workflow delete command that also deletes the Workflow's instances.","tier":"fact","section":"Ship payments somewhere else; keep Workflows for the cheap reports","interaction_risk":false,"status":"active","source_ids":["p4","s14"],"why_material":"It narrows a historically accurate GA complaint to current state.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c15","text":"A local Workflow reproduction reports SQLITE_TOOBIG for a roughly 200 KB Uint8Array step output.","tier":"independent","section":"Declaring a queue producer breaks every route under --remote","interaction_risk":false,"status":"active","source_ids":["p7","s12"],"why_material":"Serialization shape, not only documented size, can break local Workflow replay.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c18","text":"The fresh repository inventory found 30 waitUntil call sites across 9 files and 13 scheduled-handler calls.","tier":"measurement","section":"Fresh receipt: 1,000 consecutive minute ticks occupied 1,000 minute slots","interaction_risk":false,"status":"active","source_ids":["r1"],"why_material":"It measures the actual deferred-work surface.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c19","text":"The account currently has three queues, and the named dead-letter queue has a consumer attached.","tier":"measurement","section":"Fresh receipt: 1,000 consecutive minute ticks occupied 1,000 minute slots","interaction_risk":false,"status":"active","source_ids":["r2"],"why_material":"A DLQ with no consumer would only be a temporary holding area.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c20","text":"The newest 1,000 cron ledger rows occupied exactly 1,000 inclusive minute slots.","tier":"measurement","section":"Fresh receipt: 1,000 consecutive minute ticks occupied 1,000 minute slots","interaction_risk":false,"status":"active","source_ids":["r3"],"why_material":"It is a bounded delivery receipt, not a universal uptime claim.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c21","text":"996 of the newest 1,000 ticks arrived inside the first seven seconds, with a worst second of :10.","tier":"measurement","section":"Fresh receipt: 1,000 consecutive minute ticks occupied 1,000 minute slots","interaction_risk":false,"status":"active","source_ids":["r4"],"why_material":"Cron is suitable for scheduling but not sequencing.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c22","text":"Four measured idle-queue handoffs took 6–8 seconds with a median of 7 seconds under a five-second batch timeout.","tier":"measurement","section":"Measurements taken from this account","interaction_risk":false,"status":"active","source_ids":["r5"],"why_material":"It quantifies the latency cost of a durable queue handoff.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false}],"sources":[{"id":"s1","type":"specification","url":"https://developers.cloudflare.com/workers/runtime-apis/context/","title":"Workers Context API","quote":"For HTTP-triggered Workers, `ctx.waitUntil()` can extend execution for up to 30 seconds after the response is sent or the client disconnects.","summary":"Normative lifetime and cancellation boundary for deferred promises attached to an HTTP invocation.","claim_ids":["c1"],"hash":"b17014fcdf429b0f5a93ec895fdfb24aa32e1ebaf89fd49e5e22d57c626e9b8d"},{"id":"s2","type":"specification","url":"https://developers.cloudflare.com/queues/reference/delivery-guarantees/","title":"Queues delivery guarantees","quote":"Cloudflare Queues provides at-least-once message delivery by default.","summary":"Normative delivery model: a message may be delivered more than once, so consumers must be idempotent.","claim_ids":["c2"],"hash":"6e22d639a6768ecdcf25f8120a8f511a22850a7ff952055aae8e165fea6985df"},{"id":"s3","type":"publisher_documentation","url":"https://developers.cloudflare.com/queues/configuration/batching-retries/","title":"Queue batching and retries","quote":"if a batch of 10 messages is delivered, but the 8th message fails to be delivered, all 10 messages will be retried and thus redelivered to your consumer in full.","summary":"Batch sizing, timeouts, whole-batch retry behavior and per-message acknowledgement controls.","claim_ids":["c3"],"hash":"13cea8553cc3390f0a217b6a67e60486487b1a231e4ffaeef2394a3aa490b987"},{"id":"s4","type":"publisher_documentation","url":"https://developers.cloudflare.com/queues/configuration/dead-letter-queues/","title":"Dead-letter queues","quote":"A dead letter queue (DLQ) is a common concept in a messaging system, and represents where messages are sent when a delivery failure occurs with a consumer after `max_retries` is reached.","summary":"DLQ activation, retention and the boundary at max_retries.","claim_ids":["c13"],"hash":"753385a1b254580d192d590654aed9cc43edde749c160f1c3ba171fc1c97ca51"},{"id":"s5","type":"specification","url":"https://developers.cloudflare.com/queues/platform/limits/","title":"Queues limits","quote":"Each consumer invocation has a maximum wall time of 15 minutes.","summary":"Queue message, backlog, throughput, batch and consumer duration limits.","claim_ids":["c4"],"hash":"84cd2d6d6b9da23ff098346f39161125ed47431ba8f9ab9cb4004eff2a7c92b6"},{"id":"s6","type":"specification","url":"https://developers.cloudflare.com/queues/platform/pricing/","title":"Queues pricing","quote":"In most cases, it takes 3 operations to deliver a message: 1 write, 1 read, and 1 delete.","summary":"Operations-based billing, included operations and message-size multiplication.","claim_ids":["c5"],"hash":"25c9c15bec90d88f88788d5247668c48c6c610e6eaa6a5cba97be8f473ada67c"},{"id":"s7","type":"publisher_documentation","url":"https://developers.cloudflare.com/workflows/build/rules-of-workflows/","title":"Rules of Workflows","quote":"Steps should be named deterministically (that is, not using the current date/time, randomness, etc).","summary":"Step naming, deterministic execution and durable result replay requirements.","claim_ids":["c6"],"hash":"beda1fd4c1ad5368af5016f1cdb6b6027ab1af2fa67c1b8722902ad05bd0bc3c"},{"id":"s8","type":"publisher_documentation","url":"https://developers.cloudflare.com/workflows/build/sleeping-and-retrying/","title":"Sleeping and retrying Workflows","quote":"If you do not provide your own retry configuration, Workflows applies the following defaults:","summary":"Per-step retry, backoff, timeout and durable sleep configuration.","claim_ids":["c7"],"hash":"913ef32168ccf7b97b35a5b44a00848511aa3fe70b3e348f1866795a36bd2412"},{"id":"s9","type":"specification","url":"https://developers.cloudflare.com/workflows/reference/pricing/","title":"Workflows pricing","quote":"Workflows are billed on four dimensions:","summary":"The Workflows request, CPU, step and storage billing units and allowances.","claim_ids":["c8"],"hash":"d667e2cffc57e4a2994e99a9410061fb12179e3dcece8eb8817d807cfe92063e"},{"id":"s10","type":"publisher_documentation","url":"https://developers.cloudflare.com/workers/configuration/cron-triggers/","title":"Cron Triggers","quote":"When deploying a Worker with Wrangler any previous Cron Triggers are replaced with those specified in the `triggers` array.","summary":"UTC cron syntax, propagation, local testing, event history and replacement semantics.","claim_ids":["c9"],"hash":"59b6e8200dfb8bfcd8d3f95909f3e22a619290ce2ec0cd0487285d4112968806"},{"id":"s11","type":"publisher_documentation","url":"https://developers.cloudflare.com/durable-objects/api/alarms/","title":"Durable Object alarms","quote":"Alarms have guaranteed at-least-once execution and are retried automatically when the `alarm()` handler throws.","summary":"Per-object durable scheduling and retry semantics.","claim_ids":["c10"],"hash":"81f40d5a9fed250ce4b2612ccca918db31038264f21e957405a6e7f58104b55a"},{"id":"s12","type":"repository","url":"https://github.com/cloudflare/workers-sdk","title":"Cloudflare workers-sdk","quote":"Home to Wrangler, the CLI for Cloudflare Workers®","summary":"Public Wrangler and local runtime implementation containing the reported queue and Workflow development defects.","claim_ids":["c14","c15"],"hash":"d3763ebb22d055511f9e5f0c9b4b6f27c48711e1549b13b52c0c70c3230a0cf7"},{"id":"s13","type":"independent_measurement","url":"https://thisisacomputer.com/articles/cloudflare-workflows","title":"Working with Cloudflare Workflows","quote":"Making changes to durable workflows is tricky. Cloudflare has no documentation around this. You're on your own, so be careful.","summary":"Independent operator report on how changed Workflow step lists behave across deployments, explicitly separating observation from inference.","claim_ids":["c11"],"hash":"4fc68ed560a735bb663241f8509381d0e2f49b61c355db7c52f9414d26c49bc5"},{"id":"s14","type":"publisher_documentation","url":"https://developers.cloudflare.com/workers/wrangler/commands/workflows/","title":"Wrangler Workflows commands","quote":"Delete workflow - when deleting a workflow, it will also delete it's own instances","summary":"Current lifecycle commands, including delete, terminate, pause, resume and restart.","claim_ids":["c12"],"hash":"54ca354a3503f241832b70c7559012f9387698ed03a8ad6cffea7d2378f69233"},{"id":"p1","type":"github","url":"https://github.com/cloudflare/workers-sdk/issues/13816","title":"Queues: add API to immediately dead-letter a specific message","quote":"Cloudflare Queues push consumers currently expose ack/retry controls, and configured DLQs receive messages only after max_retries is exhausted.","summary":"Running Queues push consumers and finds there is no way to immediately dead-letter a message known to be non-retryable: the only options are to ack and lose the payload, burn all retries pointlessly, or hand-roll a parallel failure queue. Negative — a delivery-semantics gap.","claim_ids":["c13"],"hash":"45e8ce8d4ca566744c81fa59fc7ef1598855b2834f1a8385e8f62b392b16235a"},{"id":"p2","type":"github","url":"https://github.com/cloudflare/workers-sdk/issues/9642","title":"Queue producer binding causes 500 errors on all routes when using `wrangler dev --remote`","quote":"When a queue producer is configured in `wrangler.toml`, ALL API routes return 500 Internal Server Error when using `wrangler dev --remote`, even routes that don't use the queue binding.","summary":"Simply declaring a queue producer binding breaks every route under wrangler dev --remote, while local dev and production are fine. Eight reactions indicate others hit it too. Negative.","claim_ids":["c14"],"hash":"3de9bdd6bfd4263a7167cbc7aec6325b8dabf876a606d798bd80a4b83ef0c2ff"},{"id":"p3","type":"github","url":"https://github.com/cloudflare/workers-sdk/issues/5543","title":"Unable to test any binding that requires `--remote` with Queues","quote":"If you run a worker that uses Queues with `dev --remote`, it implodes and is completely unusable. You get obscure \"Script not found\" errors.","summary":"Because several GA bindings (Analytics Engine, Browser Rendering) only work with --remote, and Queues breaks --remote entirely, you cannot test a Worker that uses both together. Negative — a compounding hole in the local/remote story.","claim_ids":["c14"],"hash":"838a4f105442b8a5501d311295005200db6789334352e532b92ba4d1762c14ed"},{"id":"p4","type":"hn","url":"https://news.ycombinator.com/item?id=48679522","title":"OAuth for all","quote":"Cloudflare claiming Workflows had reached \"GA\" status before offering a way to delete workflows... not via wrangler, not the dashboard, not the API.","summary":"Argues Cloudflare declares products GA before basic lifecycle operations exist, using Workflows' months-long absence of any delete path as the example, with no disclaimer that the capability was missing. Negative on Workflows' production-readiness claims.","claim_ids":["c12"],"hash":"fb8555d366c400a439360c6dc7ab0bb43d8da02df18fb840137789df6d2fb18d"},{"id":"p5","type":"hn","url":"https://news.ycombinator.com/item?id=48315400","title":"Building durable workflows on Postgres","quote":"for payment integrations on northflank since its faster than cf workflows, independent of cf and its downtime and self-hostable vendor-lock-in free","summary":"Pastes their actual routing policy across three durable-execution engines: Restate for payments (faster, and insulated from Cloudflare downtime), Cloudflare Workflows only for non-critical CSV/PDF report generation because it is very cheap, DBOS where atomicity with a Postgres transaction is required. Mixed — a concrete 'when to pick Workflows' boundary.","claim_ids":["c16"],"hash":"7b2668a9e89e65e63b9ad8db2cf797fd41d3fa06464f72eed794a8b0fe50f513"},{"id":"p6","type":"hn","url":"https://news.ycombinator.com/item?id=44335222","title":"What would a Kubernetes 2.0 look like","quote":"Cloudflare Workers support Cron triggers and RPC calls in the form of service bindings. Also, Cloudflare Queues support consumer workers.","summary":"Correcting a claim that Workers are HTTP-only by pointing at the actual trigger surface: Cron Triggers, service-binding RPC, and Queues consumer Workers including HTTP short polling. Positive, and useful for the choose-between-them framing.","claim_ids":["c17"],"hash":"ebfb9c24b94df7c41877e28186579bf021ac4c190fb5b92e8c3882b9b8b982c9"},{"id":"p7","type":"github","url":"https://github.com/cloudflare/workers-sdk/issues/14101","title":"Workflow step Uint8Array triggers SQLITE_TOOBIG locally","quote":"string or blob too big: SQLITE_TOOBIG","summary":"Independent local reproduction: a roughly 200 KB Uint8Array step output fails while alternate serialization shapes succeed.","claim_ids":["c15"],"hash":"551f52b87056db1ad6504b7600266a7940129050c83a9294fb2cb0bd92c82c8b"},{"id":"r1","type":"runtime_receipt","url":"https://miscsubjects.com/api/articles/cloudflare-os-async","title":"Fresh first-party async surface inventory","quote":"JavaScript `waitUntil(` call sites | 30 across 9 files","summary":"Read-only filesystem harness counted deferred call sites, scheduled-handler calls, cron expressions, Workflow bindings and queue consumers.","claim_ids":["c18"],"hash":"427f1e5fae6abe4d603c41a9e22fce28484b5812728a67b756b6f34bb5ea2e3c"},{"id":"r2","type":"runtime_receipt","url":"https://miscsubjects.com/api/articles/cloudflare-os-async","title":"Fresh first-party queue inventory","quote":"Live queues | `loop-ingest` 4 producers / 1 consumer; `loop-ingest-dlq` 0 / 1; `loop-tasks` 3 / 1","summary":"Wrangler 4.103.0 listed the three queues and their attached producer and consumer counts without exposing ids.","claim_ids":["c19"],"hash":"87ad3caef9ab8fee5397a181cd7079df34495577486605391e6e3ea21488abb0"},{"id":"r3","type":"runtime_receipt","url":"https://miscsubjects.com/api/articles/cloudflare-os-async","title":"Fresh first-party 1,000-tick cron receipt","quote":"Minute slots inclusive | 1,000 expected; 1,000 observed","summary":"After PRAGMA schema inspection, a read-only D1 query fetched the newest 1,000 sibling.cron rows and compared their inclusive minute span.","claim_ids":["c20"],"hash":"74b20a91ed460bec135fe4eb68213484474e9384a63e4ed5790044dde7daed41"},{"id":"r4","type":"runtime_receipt","url":"https://miscsubjects.com/api/articles/cloudflare-os-async","title":"Fresh first-party cron jitter receipt","quote":"Within the first seven seconds of the UTC minute | 996 of 1,000; worst second `:10`","summary":"The same 1,000-row sample measured arrival-second distribution and gap range.","claim_ids":["c21"],"hash":"e66724effac9e85a7520509744093a5ad909459d72d49b12042d72064aef50c9"},{"id":"r5","type":"runtime_receipt","url":"https://miscsubjects.com/api/articles/cloudflare-os-async","title":"First-party queue handoff timing receipt","quote":"Median 7 seconds, on a queue configured `max_batch_size = 10`, `max_batch_timeout = 5`.","summary":"Four real enqueue-to-consumer samples measured 6–8 seconds, with the method, timestamps and API path published.","claim_ids":["c22"],"hash":"f6dbebe47776423fbbfb263c12d6af2298bd7295d35de5e3285f730f51fd00a7"}],"anecdotal_sources":[],"scientific_sources":[],"user_reports":[],"related_articles":[],"question_graph":{"slug":"cloudflare-os-async","questions":[],"evidence":[],"edges":[],"counts":{"questions":0,"evidence":0,"edges":0}},"honesty":{"active_claims":22,"retracted_claims":0,"cut_claims":0,"challenges":0,"scrub_events":0,"note":"Retracted/cut claims stay on ledger but are excluded from ask unless ?include_inactive=1"},"counts":{"claims":22,"claims_total":22,"sources":26,"anecdotal":0,"scientific":0,"user_reports":0,"questions":0,"evidence_ingests":0}}