[kaxil]

Found while testing common.ai 1.0.0rc1 (#74741). AgentOperator(durable=True) documents two behaviours it did not have.

Duplicate toolset ids. The 1.0.0 changelog and the durable execution page say every FunctionToolset, MCPToolset and DynamicToolset needs a unique id=, checked when the operator is created. Construction only checked that an id was present. Two toolsets sharing id="orders" loaded fine and then failed at run time with pydantic-ai's UserError: Two toolsets have the same id 'orders'. The operator now raises ValueError when it is created. It applies the same rule pydantic-ai's durable backend does (durable_exec/_base.py): only distinct instances of those three kinds collide, and one instance passed in two places counts once. The check covers the toolsets the agent actually runs, so agent_params["toolsets"] doesn't count when toolsets= replaces it.

A tool that defers under durable=True. The durable page says such a call fails the task with UnsupportedToolDeferralError. It actually failed with pydantic-ai's UserError: A deferred tool call was present, but DeferredToolRequests is not among output types. The operator added DeferredToolRequests to the output types only when approval was supported, so its own check was never reached. Durable runs now include it, so a deferral that ends the run fails the task with UnsupportedToolDeferralError and pushes the attempt's usage and run_id XComs, as other failed attempts do.

Why approval tools aren't refused when the Dag is parsed. A declared approval tool often never pauses a durable run. A HandleDeferredToolCalls judge can settle every call inline, conditional approval may not trigger, CodeMode reports the call back to the model, or the model may never call the tool. All of these ran to success on main, and a parse-time check would have broken them. The new tests cover the judge case under durable=True.

Without the source change, the new tests fail with DID NOT RAISE ValueError, KeyError: 'usage' and the UserError above.