Skip to content

sync_accounts: honor push_notification_config (forward, persist, deliver on account status transition) #1608

Description

@numarasSigmaSoftware

Summary

sync_accounts accepts a push_notification_config but never honors it: the account can be created in pending_approval, yet no callback is retained to notify the buyer when it later transitions to active. Deferred from PR #1546 (second-round review); the sibling context-echo and idempotency-key-preservation gaps were fixed there, but push-config forward+persist+deliver is feature-sized.

Current state (as of #1546)

  • REST parses push_notification_config (SyncAccountsBody) and forwards it into the request.
  • MCP wrapper (src/core/tools/accounts.py::sync_accounts) does not declare the field, so the envelope-tolerance middleware strips it.
  • A2A handler (_handle_sync_accounts_skill) does not forward it.
  • _sync_accounts_impl ignores the field entirely — nothing is persisted and no notification is ever sent on the pending_approval → active transition.

Scope / acceptance criteria

  1. Forward the field through every boundary. Declare push_notification_config on the MCP sync_accounts wrapper (so it is not stripped) and forward it in the A2A handler (REST already forwards).
  2. Validate + persist securely. SSRF-validate the callback URL (reuse WebhookURLValidator.validate_callback_url — the env-gated gate added in feat: AdCP 3.1.1 version negotiation, envelope tolerance, and bearer normalization (#1512) #1546) and persist it.
  3. Deliver on status transition. Reuse the existing seam that create_media_buy uses: store the config on a WorkflowStep (request_data/request_metadata) for a pending_approval account, so WorkflowContextManager._send_push_notifications() delivers the webhook when the account transitions to active. (Persistence table push_notification_configs + the workflow delivery path already exist.)
  4. BDD. In tests/bdd/features/BR-UC-011-manage-accounts.feature, make the request carry the callback URL before dispatch and graduate the registration / transition / delivery assertions (currently xfailed).

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Ready for Dev

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions