create_a2a_server() accepts push_config_store=, so an agent can persist a buyer's push-notification config — but there is no way to make the SDK actually deliver on it. The underlying handler supports it:
# a2a/server/request_handlers/default_request_handler.py (a2a-sdk 1.0.1)
98: push_sender: PushNotificationSender | None = None,
125: self._push_sender = push_sender
340: self._push_sender # delivery guarded on it being set
create_a2a_server never passes it and exposes no kwarg for it (grep push_sender adcp/server/ returns no hits), so the parameter is unreachable through the factory. Verified on 6.6.0 and v7.0.0-rc.
Effect: an agent that accepts push-notification configs through the SDK silently never sends anything. Storing a subscription that is never fired is arguably worse than refusing it, since the buyer has no signal that delivery isn't happening.
This matters for AdCP conformance, not just convenience: submitted in the spec's task-status enum is described as long-running work where "push_notification_config is an optional notification channel for terminal completion/failure," and the 3.1.1 notification-config-lifecycle storyboard grades the subscription lifecycle end to end.
Proposed change: add keyword-only push_sender: PushNotificationSender | None = None and pass it through to both DefaultRequestHandler construction sites (a2a_server.py:1182, :1227). Additive; None preserves today's behavior.
Related: this is one of the seams that would let push_config_store= be genuinely useful rather than write-only.
create_a2a_server()acceptspush_config_store=, so an agent can persist a buyer's push-notification config — but there is no way to make the SDK actually deliver on it. The underlying handler supports it:create_a2a_servernever passes it and exposes no kwarg for it (grep push_sender adcp/server/returns no hits), so the parameter is unreachable through the factory. Verified on 6.6.0 and v7.0.0-rc.Effect: an agent that accepts push-notification configs through the SDK silently never sends anything. Storing a subscription that is never fired is arguably worse than refusing it, since the buyer has no signal that delivery isn't happening.
This matters for AdCP conformance, not just convenience:
submittedin the spec's task-status enum is described as long-running work where "push_notification_config is an optional notification channel for terminal completion/failure," and the 3.1.1notification-config-lifecyclestoryboard grades the subscription lifecycle end to end.Proposed change: add keyword-only
push_sender: PushNotificationSender | None = Noneand pass it through to bothDefaultRequestHandlerconstruction sites (a2a_server.py:1182,:1227). Additive;Nonepreserves today's behavior.Related: this is one of the seams that would let
push_config_store=be genuinely useful rather than write-only.