[cli-extension] - connector-namespace trigger update drops deliveryMode and fails for Poll state changes

Start by locating the generated AAZ implementation for az connector-namespace trigger update and inspect its GET-to-instance-update-to-PUT schema, which the issue reports omits deliveryMode. Compare it with the trigger configuration properties described in the issue and identify how the update can preserve Poll while changing state. Reproduce with an existing Disabled/Poll trigger, then verify that enabling or disabling retains deliveryMode and the other core properties.

What happened?

With the latest published connector-namespace CLI wheel, 1.0.0b33, az connector-namespace trigger update --state ... fails for existing Poll trigger configurations because the update request does not retain deliveryMode.

Both directions were reproduced against controlled Dataverse polling configurations on an existing connector:

• Enabled/Poll -> --state Disabled: exit 1, InvalidRequestContent; follow-up GET remained Enabled/Poll with the original core configuration unchanged.
• Disabled/Poll -> --state Enabled: a separate, uniquely named new trigger was created through REST with Disabled/Poll (HTTP 201), and its baseline was confirmed by GET. One CLI enable attempt returned exit 1 with the same error; the final GET remained Disabled/Poll. This control ran on 2026-11-04 at approximately 00:04:50-00:04:56 UTC. No existing trigger was modified, no source item was created, and the new trigger was retained disabled.

The installed generated AAZ update implementation performs GET -> instance update -> PUT, but its schema omits deliveryMode; this is consistent with the provider reporting an empty requested mode. The CLI exposes no --delivery-mode option on trigger update.

The same CLI path is used by other polling samples, but these live reproductions establish Dataverse behavior only; SharePoint and other connectors were not independently exercised in these controls.

What did you expect to happen?

Updating a polling trigger's state should retain deliveryMode: Poll and unrelated configuration, enabling or disabling the existing trigger without deleting or recreating it.

Steps to reproduce

1. On an existing Connector Namespace connection, create a uniquely named Dataverse GetOnNewItems_V2 trigger configuration through ARM REST or Bicep with properties.deliveryMode: Poll and properties.state: Disabled.
2. GET the resource through ARM REST and confirm Disabled/Poll.
3. Run:

az connector-namespace trigger update \
  --resource-group '<resource-group>' \
  --namespace '<namespace>' \
  --name '<existing-poll-trigger>' \
  --state Enabled

4. Observe InvalidRequestContent saying that the existing delivery mode is Poll and the update requests an empty mode.
5. GET the resource again and observe that it remains Disabled/Poll.
6. The reverse transition is also affected: on an Enabled/Poll trigger, --state Disabled fails and the trigger remains Enabled/Poll.

REST workaround evidence: A full-property PUT to the same existing trigger-config resource using API version 2026-05-01-preview, explicitly retaining properties.deliveryMode: Poll, returned HTTP 200. The accepted body used the original GET's properties minus provisioningState and pollingEndpoints, preserving connectionDetails, description, metadata, operationName, typed parameters, state, and type. No top-level GET identity/system metadata was sent. The successful control restored the original Enabled/Poll configuration and confirmed all core properties by GET; it is not a claim that every possible provider-returned field is writable.

Version / build

• Azure CLI: 2.92.0
• Azure CLI core: 2.92.0
• Extension: connector-namespace 1.0.0b33
• API: Microsoft.Web/connectorGateways/triggerConfigs, 2026-05-01-preview
• OS: Windows NT 10.0.26300.0

Versions were captured immediately before the Disabled -> Enabled control. The official latest-wheel URL, https://aka.ms/connector-namespace.whl, currently redirects to the 1.0.0b33 wheel. Repository release v1.0.0b34 contains a source archive rather than a newer CLI wheel.

Relevant logs or output

Exact stderr from the Disabled -> Enabled attempt, with only the trigger name replaced:

ERROR: (InvalidRequestContent) The delivery mode can't be changed for the '<new-trigger-name>' trigger. The existing delivery mode is 'Poll' and the update requests ''. To switch delivery mode, delete the trigger and create a new one.
Code: InvalidRequestContent
Message: The delivery mode can't be changed for the '<new-trigger-name>' trigger. The existing delivery mode is 'Poll' and the update requests ''. To switch delivery mode, delete the trigger and create a new one.

The Enabled -> Disabled attempt returned the same error. Neither rejected update changed the observed resource state or delivery mode. Resource IDs, source selectors, credentials, and callback URLs are intentionally omitted.