Pimp My IDE / garage dispatch
Back to garage
October 1, 2026 | event streams / agents / receipts

Accepted is not applied.

Cloudflare's new K2 event stream separates producers from consumers with a durable ordered log. Your interface should separate those states too. One green "done" badge cannot cover storage, delivery, acknowledgment, and the business effect.

Use one receipt per boundary: accepted, retained, leased, acknowledged, and effect verified.

A stream stores the handoff.

Cloudflare launched K2 in public beta as a durable event stream. Producers append events to an ordered log. Independent consumers can read at their own pace, and subscriptions can divide work across readers.[1]

K2 builds its log on R2 object storage. Cloudflare reports that the initial design trades some producer latency for durable object storage and batching. The launch post gives about one second at the 99th percentile for produce latency.[1] That number belongs to Cloudflare's report. It is not a measurement made by this page.

The log proves that an event crossed one boundary. It does not prove what happened after the read.

Lease, acknowledgment, and effect are different records.

In K2's launch example, a consumer receives a five-minute lease on a batch. The client can acknowledge the batch, reject it for redelivery, or extend the lease.[1] An acknowledgment is a delivery decision. It should not silently double as proof that a database row changed, an email arrived, or an agent patch passed review.

Cloudflare Queues makes a related boundary explicit. Its documentation says a successful write should keep a message from being lost, and a message is not deleted until a consumer successfully consumes it. Queues does not promise publication order.[2] Product vocabulary matters. "Stored," "delivered," and "ordered" do not mean the same thing across systems.

Keep the offset attached to the claim.

Apache Kafka's introduction describes durable topics split into partitions. Kafka guarantees write order within a topic-partition, not one total order across every partition.[3] A useful receipt therefore names the stream or topic, partition when applicable, offset or event identifier, consumer identity, and the action produced downstream.

This is the practical rule for agent jobs too. If a coding agent reacts to an issue event, a stored event proves intake. A lease proves temporary work ownership. An acknowledgment proves the consumer released redelivery. The finished claim needs the exact repository revision, test result, deployment record, or other effect the task was meant to produce.

Make partial progress visible.

A single spinner followed by "done" erases the failure boundary. Show the latest supported state instead. If the event is retained but no consumer has it, say "retained." If the lease expired, say "available for redelivery." If the consumer acknowledged the batch but the downstream check is blank, say "acked, effect not verified."

That language helps operators recover. It tells them whether to republish, wait, redeliver, inspect the consumer, or check the destination. It also keeps retry logic from creating duplicate effects because someone mistook a missing final receipt for a missing event.

Interactive makeover / event receipt rail

Move the receipt one detent at a time

Traditional purpose replaced: one generic job-status badge. Better version: choose the latest observed boundary, read the exact claim it supports, and copy a handoff card that keeps all later evidence marked as required.

Receipt stage

Choose the stage this receipt must document. Selecting a stage does not verify it.

Choose the event stage this receipt must document
Receipt position

Five-detent witness rail

Effect open

The producer reports that the event was accepted.

Storage lookup, consumer delivery, acknowledgment, and the downstream effect still need evidence.

Three recovery questions

Ask where the last reliable receipt lives.

01 / PRODUCER

Was the send accepted?

Keep the response or error. A fire-and-forget call that discards errors cannot support an accepted claim.

02 / CONSUMER

Who owns delivery now?

Record the consumer, lease, attempt, and redelivery rule. Expired ownership is not completed work.

03 / DESTINATION

What proves the effect?

Use a destination check such as a revision, row, object, test result, or delivery record. Do not infer it from acknowledgment.

Sources read

Source log and evidence boundary
  1. Cloudflare, "Announcing Cloudflare K2: serverless event streams", published and read October 1, 2026. The post describes the public beta, R2-backed ordered log, subscriptions, reported producer latency, batch leases, acknowledgment, negative acknowledgment, and lease extension.
  2. Cloudflare Queues documentation, "How Queues Works", updated April 21 and read October 1, 2026. The page defines producers, consumers, successful writes, deletion after successful consumption, and the lack of publication-order guarantees.
  3. Apache Kafka 4.3 documentation, "Introduction", read October 1, 2026. The guide defines producers, consumers, durable topics, partitions, retention, and ordering within a topic-partition.
  4. Hacker News item 49921923, fetched from the official API on October 1, 2026. It identified the K2 launch during a scan that also covered Cloudflare Clef, GitHub Trending, NVIDIA OpenShell, Cursor plugins, and Context Mode. It is a discovery source, not evidence for product behavior.

Evidence boundary: Product behavior and latency in this article come from the named publishers. Pimp My IDE did not run K2, Cloudflare Queues, or Kafka for this dispatch. The receipt rail is a teaching tool. Every generated field is a placeholder until an operator attaches real event and destination evidence.