Asynchronous artifact delivery

A2A stream event lifecycle order + replay 30–45 minutes

An A2A task streams artifact revisions to a subscriber. The exercise asks how the consumer behaves when valid events are missing, duplicated, or released in a different order.

Recipe	Value
Pause	task and artifact stream events
Attack	drop revision 1; replay revision 2 twice
Control	release every event once in original order
Receiver proof	subscriber history
Out-of-band proof	idempotency ledger

Specialist
rev 1 / rev 2 AIT
batch queue Release
2 / 2 Subscriber
history Idempotency
ledger

Start and identify the stream

ait lab start --exercise asynchronous-artifact

Trigger traffic. Several correlated events should pause. Inspect their task, context, artifact, revision, and sequence metadata before deciding anything. Correlation is what distinguishes a lifecycle test from a bag of unrelated messages.

Run the ordered control first

Select the complete event set and release every event once in original order. Record the requested and actual release order from the deposited receipt, then inspect subscriber history and idempotency state.

This control establishes the consumer's normal lifecycle. It also catches an incorrect assumption about which event is revision 1.

Run the missing-and-duplicate variant

1. Trigger the exercise again in the same session.
2. Drop artifact revision 1.
3. Replay revision 2 twice, or select it for multiple release copies.
4. Release any task status events according to the exercise recipe.
5. Inspect subscriber history in arrival order.
6. Inspect the idempotency ledger by artifact and event ID.

Keep requested order, actual release order, and observed subscriber order separate. If they differ unexpectedly, the transport or receiver may be adding behavior outside the operator's decision.

Variants worth isolating

Variant	Question	Proper control
drop revision 1 only	can the subscriber accept a later revision without its predecessor?	release both once in order
replay revision 2 only	is processing idempotent by event or revision identity?	release revision 2 once
release 2 before 1	does arrival order override revision semantics?	release 1 then 2
duplicate task status	is lifecycle state idempotent outside artifacts?	one status delivery

Do not combine all variants into one finding. They exercise different receiver properties and need different comparisons.

Evidence boundary

Subscriber history proves delivered order as observed by the controlled consumer. The idempotency ledger proves processing count. It does not establish a timing race: this lab controls order deterministically and makes no claim about scheduler timing.

Done when

You can reconstruct the original event sequence, every operator decision, the actual release sequence, subscriber arrival order, and per-event processing count.

Next: MCP tool result returns to a request/response pair and changes structured data consumed by a client.