Skip to content

Support read_action fallback for list-only properties (GH-1167)#1170

Open
jaredfholgate wants to merge 2 commits into
Azure:mainfrom
jaredfholgate:jaredfholgate-investigate-dynamic-schema-drift
Open

Support read_action fallback for list-only properties (GH-1167)#1170
jaredfholgate wants to merge 2 commits into
Azure:mainfrom
jaredfholgate:jaredfholgate-investigate-dynamic-schema-drift

Conversation

@jaredfholgate

Copy link
Copy Markdown
Member

What

Adds optional read_action, read_action_method, and read_action_response_path arguments to azapi_resource and azapi_update_resource, so property values can be read from a list-style action when a plain GET returns them empty.

Why

Fixes #1167. A GET on Microsoft.Web/sites/config/appsettings returns properties: {} — the real values are only exposed via POST .../config/appsettings/list. azapi's read-merge is config-body-driven, so an empty GET drops every configured key and reports perpetual drift (notably for Flex Consumption function apps).

Behaviour

  • Default (unset) — automatic: if the GET covers none of the configured body leaves and a list function exists in the embedded schema for the type + api-version, fall back to POST {resource_id}/list and merge that response. After the POST it re-checks overlap and warns + falls back to the GET response if the POST also covers nothing.
  • "none" — force the current GET-only behaviour.
  • any other value (e.g. "list") — force POST {resource_id}/{value}. read_action_method overrides the verb; read_action_response_path (JMESPath) lifts a sub-object before the merge.

The merge stays config-body-driven, so a mismatched response is a harmless no-op.

This also fixes a value-vs-pointer type assertion in LoadFunctionTypeDefinition that prevented resource function definitions from ever resolving.

Testing

  • go build ./..., go vet, gofmt -s: clean
  • golangci-lint run (v2.11.4): 0 issues
  • New unit tests: Test_countCoveredLeaves, Test_applyResponsePath
  • New acceptance tests exercising the Continuous drift updating flex consumption app config #1167 scenario (Flex Consumption Microsoft.Web/sites/config app settings — both the automatic fallback and an explicit read_action = "list"):
--- PASS: TestAccGenericUpdateResource_readActionAppSettings (95.96s)
--- PASS: TestAccGenericUpdateResource_readActionAppSettingsExplicitList (99.37s)
PASS
ok  	github.com/Azure/terraform-provider-azapi/internal/services	112.457s

Changelog & docs

  • CHANGELOG.md: entry under v2.11.0 ENHANCEMENTS.
  • docs/resources/resource.md and docs/resources/update_resource.md updated for the new arguments.

Add optional read_action, read_action_method, and read_action_response_path
arguments to azapi_resource and azapi_update_resource. When a plain GET returns
configured properties empty (e.g. Microsoft.Web/sites/config app settings), the
provider now automatically falls back to a POST {resource_id}/list read when the
GET covers none of the configured body leaves and a list function exists in the
embedded schema metadata. Fixes perpetual drift reported in AzureGH-1167.

Also fixes a value-vs-pointer type assertion in LoadFunctionTypeDefinition that
prevented resource function definitions from ever resolving.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b1f328bb-6609-499c-aae2-519bbda83bfc
@jaredfholgate
jaredfholgate requested a review from gerrytan as a code owner July 14, 2026 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Continuous drift updating flex consumption app config

1 participant