Design: project x-ms-trigger routes as Connector Namespace callback contracts

[daviburg]

Problem

The Python direct-client generator exposes Swagger routes marked x-ms-trigger as callable data-plane methods. For example, Python SDK PR #54 generates create_subscription_async for Azure Event Grid CreateSubscription and subscribe_on_a_business_event_async for Dynamics AX SubscribeOnABusinessEvent.

These operations are not ordinary connector actions. The Connector Namespace architecture registers them with Microsoft.Web/connectorGateways/.../triggerConfigs; Connector Namespace monitors the connector and POSTs the callback payload to the application endpoint. The .NET SDK projects the same operations as trigger constants, parameter metadata, and typed TriggerCallbackPayload<T> registrations rather than client invocation methods.

This is not a naming issue. Python snake_case is required by the Azure SDK Python guidelines and must remain the public Python convention.

Evidence

• In the PR Add new connectors (Phase 3) #54 Swagger snapshot, CreateSubscription is x-ms-trigger: batch, non-deprecated, and x-ms-visibility: important.
• SubscribeOnABusinessEvent is x-ms-trigger: single, non-deprecated, and x-ms-visibility: important.
• The generated Python methods issue POST calls to those trigger routes through the connection runtime URL.
• The paired BPM generator's Python path retains trigger routes in its public method set, while the C# target projects trigger metadata and callback payload contracts.
• The .NET SDK trigger-registration workflow documents the intended lifecycle: create a Connector Namespace trigger config, then receive callbacks at the compute host.

Expected Design

1. Keep Python public names idiomatic: snake_case methods and parameters, PascalCase types.
2. Do not generate direct-invocation methods for x-ms-trigger routes.
3. Generate language-appropriate trigger operation IDs, required parameter metadata, and typed callback payload models when the callback body has a JSON schema.
4. Register triggers through the Connector Namespace trigger-config API; Connector Namespace, not application code, invokes the callback.
5. Keep x-ms-visibility: internal discovery operations internal, emitting them only when dynamic metadata requires them.

Regression Coverage

Add generator and SDK contract tests that use a Swagger fixture containing:

• an important non-deprecated action;
• an important non-deprecated x-ms-trigger route; and
• an internal dynamic-values discovery route.

Assert that the action becomes a callable Python method, the trigger becomes trigger registration/callback metadata rather than a callable method, and the discovery route is not exposed as an ordinary public invocation. Add cross-language parity validation against the same pinned Swagger fixture.

Related

• Python SDK PR Add new connectors (Phase 3) #54
• BPM generator PR 16445892
• .NET SDK trigger-registration skill and docs/triggers.md

[hallvictoria]

Expected design point	Verification
No direct-invocation methods for x-ms-trigger routes	0 callable trigger methods remain across all connectors (create_subscription, subscribe_on_a_business_event, workflow_create_trigger, flow_v1_processes_flow_triggers, trig_new_activity, trig_new_deal all gone)
Trigger operation IDs + required-param metadata + typed callback payload models	7 connectors now emit a module-level TRIGGER_OPERATIONS: Dict[str, Dict[str, Any]] registry (azureeventgrid, azureiotcentral, dynamicsax, pipedrive, plumsail, sql, zendesk) with operation_id, required_parameters, and callback_payload_type
The two named examples	azureeventgrid CreateSubscription and dynamicsax SubscribeOnABusinessEvent (the exact issue examples) are now registry entries; dynamicsax carries the typed BusinessEventSubscriptionResponse callback payload
snake_case public names preserved	Non-trigger actions still snake_case
Regression coverage	Generator tests (DirectClientPythonGeneratorTests, exit 0) + per-connector TestTriggerOperations classes