Repository navigation
Make AZD postprovision credential-aware and safely initialize settings and Search #1489
Description
Issue
AZD postprovision can fail on Cosmos accounts with local authentication disabled even when the runner has valid Entra data-plane access. The former key-only probe treated authentication failures as firewall propagation problems and could replace existing network rules with a runner-only rule.
Deployment-time settings writes also need to participate in the shared settings-store publication protocol, and fresh deployments require manual Search-index setup before document search can work.
Steps to Reproduce
- Deploy with managed_identity authentication against a Cosmos account with disableLocalAuth enabled.
- Run azd up or the postprovision hook from an authorized runner.
- Observe the key-based probe fail and the hook attempt an IP-rule update and propagation wait.
- In a Redis-enabled app, run the former postconfig writer while other workers update settings; its direct whole-document upsert bypasses coordinated shared-cache publication.
- On a deployment without Search indexes, use document search before manually creating the indexes in Admin Settings.
Expected Behavior
Use the selected deployment credential and environment; distinguish authentication and network errors without changing firewall policy. Publish intended settings changes with Cosmos concurrency checks and the existing shared Redis protocol. Create only missing Search indexes from the application schemas, preserving existing indexes and data.
Scope and Related Work
- Cosmos database/container creation and schema drift remain tracked by Managed Identity Auth for Cosmos DB for Deployment and Updates to the Application #693 and Managed identity cannot create Cosmos containers: data-plane RBAC has no create action, azd deploy never runs Bicep, and deployer container lists have drifted #1471; this issue does not claim to solve them.
- Admin settings can revert across workers after successful saves #1477 and merged PR [BREAKING] Fix cross-worker settings consistency and Redis Explorer #1478 established the runtime shared-settings protocol. This issue covers adopting that protocol in the deployment writer.
- Implementation is in PR Fix deployment authentication, settings publication, and Search initialization #1488, targeting Development, commit b9a063a.
- Versions: application 0.261.028; deployer 1.0.31.
Acceptance Criteria
- Managed-identity Cosmos checks use the deployment runner's tenant-scoped Entra credential; key mode explicitly checks whether local auth is allowed.
- Windows and POSIX postprovision never change Cosmos firewall rules or silently fall back from Entra to keys.
- Hook lookups and role commands use the selected deployment environment/subscription, with actionable failures for missing required outputs.
- Postconfig consolidates Redis assignments and uses the shared OCC/fenced publication store, preserving concurrent unrelated edits and external-cache settings.
- Publication failures are not reported as success; active Redis connection migrations are refused rather than performed implicitly.
- Missing personal/group/public Search indexes are created from app JSON schemas; existing indexes are untouched, and permission/service failures do not trigger creation.
- Add offline behavioral tests for auth, environment selection, concurrency, publication failures, reruns, index races, and both platform hook paths.
- Complete PR review and merge into Development.
- Validate the new hook implementation in Azure using a runner with the documented Cosmos, Redis, and Search data-plane permissions.
Validation
- 184 focused tests passed; 18 existing return-value warnings.
- PowerShell/POSIX syntax and offline hook execution tests passed.
- Broken-access-control, XSS, and whitespace checks passed.
- Documentation quality: 6/6 passed. Surface coverage: 6/7; generated inventory mismatch also reproduced on unmodified Development and left out of scope.
- No live cloud resources were changed during implementation/testing of this PR.
Operational Requirements
The runner needs approved network access and service data-plane permissions. Redis publication requires a suitable Redis database access policy; resource Owner alone is not sufficient. The change does not create policy exemptions, open firewalls, or enable local authentication. Active-cache migrations and existing Search schema upgrades remain administrator-managed.
Priority: P1. Assignee: Paul Lizer (@paullizer). Estimated size: M.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsIn review
Activity
Document deployment reliability release and tracking issue
paullizer commentedon Sep 30, 2026
Azure validation of the new postprovision flow
This covers the open item "Validate the new hook implementation in Azure using a runner with the documented Cosmos, Redis, and Search data-plane permissions." It was run on 2026-09-30 against a SimpleChat POC deployment.
Environment
AUTHENTICATION_TYPE=managed_identity.Balanced_B0with access keys disabled (Entra ID only), plus Azure AI Search.paullizer-react-v2-uiat 4f77838, deployer 1.0.32. The post-provision files involved (postconfig.py,deployment_configuration.py,deployment_cosmos.py) are identical onDevelopment.What worked
[1/4]granted, or confirmed, the user runner's Cosmos control-plane and data-plane roles.[3/4]reached Cosmos with the runner's tenant-scoped Entra credential. It used no keys and changed no firewall rules.Search indexes created: none (already exist)).Settings saved and verified). The settings revision went up by one, and the settings snapshot was present in the new cache afterwards.Problems found (tracked separately)
postconfig.pycallsCosmosClient.close(), which azure-cosmos 4.9.0 does not have. Postconfig exits 1 afterSettings saved and verified, and the hook skips the[4/4]restart, so every provision reports failure. The issue includes a verified patch.defaultaccess policy assignment by hand. On a firstazd upwith Entra-only Redis, this means no settings are written.manageddefault, it gets a second cache and stops at the migration guard. The migration guide doesn't cover this. The issue includes the cutover procedure that worked here.I'm leaving the validation checkbox open until #1589 is fixed, because the hook can't report success before then.