I built this at 3ad7e3f on net10.0 and ran the terminal and cancel tests plus a focused repro. The direction is right and two parts land cleanly: the terminal guard on the status and message projection paths, and holding the per-task lock across the cancel so the check-then-act is atomic and concurrent cancels serialize. Three gaps remain, most to least severe. It is also currently conflicting with main. The Copilot review flagged these; this is an independent confirmation on a built checkout, with a repro and fix directions.

1. The terminal guard is bypassed by full-task replacement. TaskProjection.Apply returns streamEvent.Task at the top, before GuardNotTerminal is ever reached (the guard lives only in ApplyStatus and ApplyMessage, on the post-copy path). So an agent that emits a full Task object in Submitted or Working overwrites a terminal task, which is exactly the state-machine violation the PR sets out to prevent. A repro over all four terminal states passes: the terminal task is replaced with Submitted, no throw. Guarding the streamEvent.Task branch too (reject a terminal to non-terminal full replacement) closes it.

2. The per-task lock can lose exclusivity while held. ChannelEventNotifier.RemoveChannel removes _taskLocks[taskId] when the subscriber set empties. AcquireTaskLockAsync verifies ReferenceEquals after the wait, which catches eviction while waiting but not eviction while another holder is already inside: if the entry is evicted during a held lease, a concurrent acquirer GetOrAdds a fresh semaphore, sees it as live, and enters alongside the current holder. This coupling pre-dates the PR, but widening the cancel to hold the lock across the whole operation enlarges the window in which a subscriber dropping its last channel collides with a cancel. Decoupling the lock registry from the subscriber lifecycle (do not evict _taskLocks in RemoveChannel, or refcount leases) would make the lock dependable.

3. Cancellation registration races the cancel lock (return-immediately and streaming sends only). Those send paths register the background CancellationTokenSource via _backgroundCancellations.GetOrAdd outside the notifier lock that CancelTaskAsync now holds. A send that already passed its terminal check can register a fresh CTS after cancel's TryRemove ran, so that background handler is never cancelled. The ordinary non-return-immediately send does not use this CTS path. Registering or re-checking the CTS under the same per-task lock would close the window.

Net: the status and message terminal guard and the cancel serialization are good; the remaining exposure is the unguarded full-task replacement (1) and the two residual races (2, 3) that the wider lock scope interacts with. Happy to help whichever way you take it.

We have rights to resolve the conflicts and resolve the noted issues. Depending on if ez-lbz would rather run with it instead.

Thanks — please go ahead, the PR is yours to run with. maintainer_can_modify is enabled on fix/state-machine-cancel-race (head 3ad7e3f), so you can push to the branch directly or lift the commits into a new one, whichever is easier; I will not push to it from here. Two notes for the handoff. Gap 1 — the full-task replacement path in TaskProjection.Apply returning streamEvent.Task before GuardNotTerminal is reached — is squarely inside this PR's scope and is what I would have fixed next. Gaps 2 and 3 are older than this PR, as @chopmob-cloud noted: _taskLocks.TryRemove in ChannelEventNotifier.RemoveChannel runs whenever the last subscriber disconnects, and the background CTS registration in SendMessageAsync sits outside the notifier lock that CancelTaskAsync now holds, so both may be cleaner as their own change rather than folded in here. Happy to review once you have a branch, or to answer anything about the original intent.

@ez-lbz @chopmob-cloud — could you both please consider the following detailed race-condition review before this is merged?

I would not merge the current revision yet. I found one critical race introduced by the latest cleanup design, three additional high-confidence concurrency bugs, and several secondary issues.

1. Streaming ownership is released before persistence completes

ReleaseBackgroundCancellationWhenCompletedAsync waits for eventQueue.Completion and agentTask, but channel completion only means the writer completed and the final item was dequeued. It does not mean the stream consumer finished ApplyEventAsync.

A valid interleaving is:

1. The handler writes its final InputRequired or Completed event and finishes.
2. The stream enumerator dequeues that event.
3. eventQueue.Completion completes.
4. The release task acquires the task lock and removes _backgroundCancellations[taskId].
5. A continuation reserves the task and reads the old state.
6. The original stream then persists its final event.

This permits a new handler to start before the preceding operation's final state is persisted. The new GivenStreamingHandlerFinishesAtInputRequired... test cannot detect this because it invokes the continuation only after MoveNextAsync has returned, which is after ApplyEventAsync.

The durable fix is a server-owned event pump that drains the agent queue, persists each event, forwards the persisted event to the client-facing channel, and releases the reservation only after that pump completes.

2. Stream cancellation loses the current event

The streaming loop dequeues a response and then calls ApplyEventAsync using the HTTP/client cancellation token. If the client disconnects while persistence is waiting for the task lock or store, the response has already left the queue. The finally drain processes only the remaining items, so the dequeued response is permanently lost.

That conflicts with reconnect/resubscription semantics because GetTask and a later subscription cannot recover an event generated by the handler. Once an event has been dequeued, its persistence should use a server-lifetime token rather than the client connection token. The server-owned persistence pump above would address this as well.

3. Concurrent subscriber creation can be orphaned

RemoveChannel removes the dictionary entry while holding only lock (set). A failing interleaving is:

1. Subscriber A starts removing the last channel and locks the subscriber set.
2. Subscriber B obtains that same set from _subscribers, then waits for its lock.
3. A removes _subscribers[taskId] and unlocks.
4. B adds its channel to the now-orphaned set.
5. Notify looks in _subscribers, finds nothing, and drops subsequent events.

B can then wait forever because its channel is neither notified nor completed. The existing concurrency test checks only for exceptions/deadlocks, not delivery. Creation and last-channel removal need common per-task serialization or reference-counted subscriber-set retirement.

4. Blocking sends are outside the operation-reservation model

Only return-immediately and streaming requests reserve an operation. Default blocking sends do not reserve the task, use only the request token, are absent from _backgroundCancellations, and therefore cannot be stopped by CancelTaskAsync.

Consequences include:

• With AutoAppendHistory=false, cancellation can persist a terminal state after context resolution but before the stale terminal check and handler start.
• Blocking sends can overlap other blocking, streaming, or return-immediately operations for the same task.
• CancelTask can store Canceled while the original handler continues external work because its execution token is unrelated to the per-task cancellation source.

Every task-associated send should use the same operation lease. Reservation, terminal recheck, and history append should occur atomically, and blocking handlers should receive a linked caller/per-task cancellation token.

5. Terminal tasks still accept artifact mutations

ApplyStatus, ApplyMessage, and full-task replacement call GuardNotTerminal; ApplyArtifact does not. A handler can emit Completed followed by a TaskArtifactUpdateEvent, and the artifact will be persisted onto the completed task.

This conflicts with terminal-task immutability and the rule that no further stream updates follow a terminal state. Artifact application should use the same terminal guard, with regression tests for all terminal states.

6. Old streaming drains can remove newer tracking

Streaming cleanup releases the reservation and then calls _backgroundTasks.TryRemove(taskId, out _). In that window, a new operation can reserve the task and add its own drain under the same key. The old drain can then remove the new tracking entry, allowing DisposeAsync to stop tracking active work.

Removal needs to be identity/ownership-safe rather than key-only. A single operation object holding the CTS, handler task, persistence task, and drain completion would simplify this ownership considerably.

7. Locking does not extend across server instances

All atomicity depends on a process-local ChannelEventNotifier, while ITaskStore exposes unconditional read and save operations with no version/CAS contract. Two server instances sharing one durable store can both read Working, independently derive updates, and overwrite one another.

If the SDK supports only one server instance per task partition, that restriction needs documentation. Otherwise the store contract needs optimistic concurrency or conditional writes.

A2A specification comparison

The current implementation can violate the latest lifecycle expectations because generated events may be lost after streaming disconnection, a continuation can begin before the preceding final state is durable, terminal tasks can receive artifact updates, cancellation does not stop blocking execution, and subscriber reconnection can silently lose live events.

Relevant references:

• A2A 1.0 specification
• Life of a Task
• Streaming and Asynchronous Operations

@ez-lbz @chopmob-cloud #7 is not unique to this PR. I noted that early on in other cases. See also: #463