[SQL] Add short-term backup retention immutability support

[svmicano]

🤖 PR Validation — ⚠️ Review suggested

Breaking Changes	Tests
⚠️ None	️✔️ 130/130

⚠️AzureCLI-BreakingChangeTest

⚠️sql

rule	cmd_name	rule_message	suggest_message
⚠️ 1006 - ParaAdd	sql db str-policy set	cmd sql db str-policy set added parameter lock_immutability
⚠️ 1006 - ParaAdd	sql db str-policy set	cmd sql db str-policy set added parameter yes
⚠️ 1008 - ParaPropAdd	sql db str-policy set	cmd sql db str-policy set update parameter diffbackup_hours: added property type=int
⚠️ 1008 - ParaPropAdd	sql db str-policy set	cmd sql db str-policy set update parameter retention_days: added property type=int
⚠️ 1009 - ParaPropRemove	sql db str-policy set	cmd sql db str-policy set update parameter retention_days: removed property required=True
⚠️ 1006 - ParaAdd	sql midb short-term-retention-policy set	cmd sql midb short-term-retention-policy set added parameter lock_immutability
⚠️ 1006 - ParaAdd	sql midb short-term-retention-policy set	cmd sql midb short-term-retention-policy set added parameter yes
⚠️ 1008 - ParaPropAdd	sql midb short-term-retention-policy set	cmd sql midb short-term-retention-policy set update parameter retention_days: added property type=int

Related command

• az sql db str-policy set, show, and wait
• az sql midb short-term-retention-policy set and show (live and restorable dropped databases)

Description

Add short-term backup immutability support using 2026-08-01-preview, with the final async SET result aligned with Azure PowerShell PR 30215.

• Add nullable --lock-immutability and --yes/-y to both SET commands. Only true prompts, with an irreversible-action warning. Decline/non-interactive confirmation failure sends no update and emits no result; --yes bypasses confirmation.
• Reject --lock-immutability with --deleted-time, including explicit false, before HTTP. Never serialize that property for dropped MI databases.
• Surface the service's immutabilityStatus on SET/show for SQL Database and live/dropped MI databases, retaining flattened CLI output and nested systemData.
• SQL Database retention remains optional for differential-only input; omitted settings are not serialized as null. MI retention remains required, including support for zero on dropped databases. SQL DB lock-only input is serializable but is rejected by the tested service; the corrected help example supplies explicit retention.
• Generate SDK-independent STR request/response schemas and HTTP operations with AAZ. Retain the existing custom registrations, cloud endpoints, authentication, URL escaping, --ids, wait and --no-wait, with a small compatibility adapter for omitted values and completion polling. azure-mgmt-sql==4.0.0b22 is unchanged; a whole-module migration to the hybrid models in 5.0.0b2 is out of scope.

Generated-command customization review (2026-10-19)

Addressed the operations-directory and generated-inheritance review comments in fc175e95adfc913b105e4af134fc9ed2f551f8e1.

• Moved the compatibility customizations into sql/operations/str_policy.py with a package initializer and updated wrapper imports. All six commands directly inherit their generated AAZ command; all three customized PUT operations directly inherit their generated operation. Shared argument normalization and polling logic use ordinary functions, with no custom classes directly inheriting core AAZCommand or AAZHttpOperation.
• Preserved omitted-argument/default-policy handling, integer differential-interval serialization, confirmation and dropped-database guards, standard ARM final policy GET, no-wait behavior, and public command compatibility. Generated files, scenario cleanup fixes, and all recordings are unchanged.
• With explicit approval, reconciled the four older local STR files with the published PR in the existing worktree. The complete 52-test published baseline passed before refactoring. After refactoring, 53 unique tests passed, zero failures/errors/skips, in 56.436 seconds: 35 CLI/HTTP unit tests, 13 safety tests, and all five recorded scenarios. The new regression checks direct generated inheritance for all six commands and three customized HTTP operations.
• Validation used this worktree's CLI/core/test SDK source, an empty Azure configuration, live-target flags removed, and network connections blocked. Scoped flake8, customization pylint (10.00/10), package discovery, whitespace checks, and editor diagnostics passed. No new checkout, live Azure operations, or recording changes were needed. Hosted CI must validate this new head independently of prior results.

Scenario cleanup safety (2026-10-19)

Commit 48a4c88fac189658c1b07b896bd7ee376daf986c addresses Copilot finding 4260152815, confirmed by the X Engineering Agent review.

• MI creation now retains the successful command result, marks the owned database for cleanup, then checks name/status. A failed output assertion no longer leaves cleanup disabled.
• SQL DB creation likewise marks ownership before JSON parsing or output assertions. Existing keep-database behavior, pre-create absence checks, and scoped-write guards are unchanged.
• Two new offline regression methods exercise both scenario types: wrong name, non-Online status, malformed/null JSON, failed creation, an existing database, and a failed absence probe. They execute the real assertion/registered-cleanup paths with mocked command execution, verify exactly one deletion of the owned target after successful creation, and no deletion after failed creation or an unproven absence check. Both methods pass; six failing subtests reproduced the defects before the fix.
• Earlier cleanup validation: 46 unique tests passed, zero failures/errors/skips, in 44.077 seconds: 28 CLI/HTTP tests, 13 safety tests, and all five recorded scenarios. Network connections were blocked and Azure configuration was empty. Scoped repository-configured flake8, whitespace checks, and editor diagnostics passed. No live Azure operations or recording changes were needed.
• Historical validation scope: the earlier cleanup-only validation preserved four pre-existing local STR versions and excluded them from that commit, so its 46-test result was a working-tree result. Those files have now been reconciled with the published AAZ-based head with explicit user approval, and the complete 52-test baseline plus the 53-test refactored suite passed in the same worktree as documented above. Earlier isolated-checkout/export attempts were stopped and their temporary artifacts removed.
• The commit contains only the two scenario test files. Production adapters, generated command bases, and upstream AAZ models are unchanged.

Integer differential-backup interval serialization (2026-10-16)

Commit 03307dd24188df4fce24d1223c51430d19eb144f fixes a regression found by live SQL Database validation: AAZ's generated numeric schema serialized --diffbackup-hours 12/24 as JSON 12.0/24.0, which the service rejected with InvalidResourceIdSegment. An integer-payload REST control was accepted.

The SQL Database custom operation now normalizes only a present, integral diffBackupIntervalInHours value after generated serialization, and explicitly rejects fractional input instead of truncating it. Omitted fields stay omitted; the other properties, MI operations, response schemas, confirmation, and completion polling are unchanged. Generated Python files and the upstream AAZ models were not hand-edited or changed; this compatibility override survives regeneration.

Validation for this fix:

• Before fix: all three new regression methods failed (17 failing subtests). They assert the exact JSON integer type rather than numeric equality.
• After fix: 50 offline unit/safety/recorded-scenario tests passed, zero failures/errors/skips, with socket connections blocked. This includes 34 CLI/HTTP unit tests, 11 safety tests, and the five existing checked-in recordings.
• Live: eight interval updates passed on the two disposable SQL databases created during the authorized live run, one Locked and one Enabled: 12/24 hours with normal completion and --no-wait, including explicit retention/lock preservation. A transport guard checked the actual outgoing JSON integer type and permitted writes only to these two policies.
• The live check restored both original 24-hour intervals, retention periods, and lock states. All pre-existing MI/SQL databases, their policies, and parent configurations were verified unchanged. No new databases or locks were created for this fix.
• Passed: scoped flake8, adapter pylint (10.00/10), compilation, and whitespace checks.

The earlier broad SQL live scenarios failed before this correction; they are not being relabeled as passes. The post-fix live validation targeted the affected field and its combinations. The MI and isolated SQL locking scenarios had already passed live and offline replay.

Exact additional validation commands (from the CLI worktree root; all exited 0):

# PASS: eight real updates; integer JSON tokens verified; policy values restored.
& 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe' -u 'E:\CLI\aaz-env\validate_str_integer_live.py'

# PASS: scoped style checks.
& 'E:\CLI\aaz-env\Scripts\python.exe' -m flake8 --append-config '.flake8' 'src\azure-cli\azure\cli\command_modules\sql\operations\str_policy.py' 'src\azure-cli\azure\cli\command_modules\sql\tests\latest\test_sql_str_policy.py'

# PASS: adapter pylint, 10.00/10.
$env:PYTHONPATH='E:\CLI\azure-cli-str-immutability\src\azure-cli;E:\CLI\azure-cli-str-immutability\src\azure-cli-core;E:\CLI\azure-cli-str-immutability\src\azure-cli-testsdk;E:\CLI\str-env\Lib\site-packages;C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages'
& 'E:\CLI\aaz-env\Scripts\python.exe' -m pylint --rcfile 'pylintrc' --jobs 1 'src\azure-cli\azure\cli\command_modules\sql\operations\str_policy.py'

# PASS: compilation.
& 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe' -m compileall -q 'src\azure-cli\azure\cli\command_modules\sql\operations\str_policy.py' 'src\azure-cli\azure\cli\command_modules\sql\tests\latest\test_sql_str_policy.py'

The full offline command below was rerun unchanged and now reports 50 passing tests. New hosted CI results must be checked for this commit before merging.

AAZ generation (2026-10-16)

Commit 9451dbe62e486904492d957059b857d154b702a0 replaces the handwritten STR request/response schemas with six command bases generated by aaz-dev-tools 4.7.1:

• SQL Database policy GET/PUT: sql/aaz/latest/sql/db/str_policy.
• Live managed database policy GET/PUT: sql/aaz/latest/sql/midb/short_term_retention_policy.
• Restorable dropped managed database policy GET/PUT: the restorable_dropped child package.

The bases remain unregistered: the existing custom handlers preserve public command names, aliases, required MI retention, database-ID handling, conditional irreversible-action confirmation, and rejection of either lock flag value for dropped databases. No new public command group is introduced. The dropped-policy model hides the shared-schema lock argument.

operations/str_policy.py contains compatibility adapters, including the integer wire-type correction above, not manually maintained API schemas. Its shared PUT operation override intentionally retains the final policy GET described below: the current REST specifications declare final-state-via: location, which must not undo the already-tested PowerShell alignment when regenerating.

Generation inputs: Azure/azure-rest-api-specs commit 2e2b290fd446b03bbddcdc31098ff97e7218f0cf, SQL 2026-08-01-preview; AAZ base commit f4676b10d373ec9f5c0b63b986fe2a1832682814. Generated files were not hand-edited. An unrelated generator change to the existing MI start-stop-schedule registration was excluded.

Upstream models: Azure/aaz#1130.

Final policy GET alignment (2026-10-13)

Commit 93e16b8f2253fbdccb1a8337cc2dca763d6cae83 removes the explicit final-state-via: location override from the shared STR PUT operation. For the Azure-AsyncOperation flow recorded for SQL Database and MI:

1. PUT the policy.
2. Poll async status until Succeeded.
3. GET the original policy resource URL and return that policy.

This matches the PowerShell recordings, whose final policy GET belongs to the SET operation. It replaces the previous OperationResults GET; it does not add a second final read, synthesize Locked, retry until a desired immutability status, add fixed delays, or fill omitted request properties.

• --no-wait still submits once, without polling or a final GET, and emits no result.
• Failed/canceled operations propagate their error before any final GET. Errors from the final policy GET are also propagated.
• Synchronous 200 responses without polling headers and Location-only responses retain standard ARM behavior: return their response without an additional policy GET. Unit tests cover these distinct paths; no unconditional readback is claimed.
• SQL DB and MI locking scenarios now assert Locked on SET itself, as well as through independent policy GETs. All five affected scenarios were genuinely re-recorded live on 2026-10-13; response statuses and URLs were not hand-edited to pass playback.
• Fixed the recording sanitizer to preserve non-JSON/non-object gateway responses instead of masking HTTP retry/error handling with a JSON parsing exception.
• Isolated process-wide CLI session caches in unit-test setup/cleanup so temporary configuration directories do not contaminate later scenario tests. Help regression coverage tolerates normal line wrapping.

Wait-command compatibility

The earlier fix in 3333619a720b9deb77c784134f1e276500dda0c4 remains intact: az sql db str-policy wait --policy-name default is accepted and --policy-name remains required, matching the exact PR base cc010d2104b3ab0089c33fb7eac8816c260a11ac. A dedicated getter forwards and URL-escapes the supplied name; show/set and MI commands still use the default policy without a new public option. Regression coverage includes --ids, encoded names and missing-option rejection without HTTP. No compatibility-rule suppression or exception is requested.

Remaining service limitations and release checks

• OperationResults can still report Disabled while the actual policy GET reports Locked. Earlier raw SQL DB recordings and 24 paired MI diagnostic reads over approximately 144 seconds demonstrated this backend inconsistency. The CLI now uses the standard final policy GET for the recorded async flow; this does not claim the backend endpoint is fixed.
• New SQL DB policies may initially report Disabled before becoming Enabled. The new-DB locking test retains its 900-second readiness timeout and refuses to lock before Enabled; independent post-lock checks retain their 300-second timeout. A previous Oct13 initialization failure is not counted as passing. The refreshed new-DB locking recording passed.
• The tested SQL DB backend rejects lock-only PUTs with InvalidParameterValue; including current retention succeeds. On a locked policy, retention updates with the lock flag omitted can be interpreted as unlocking. Help now documents explicit retention when locking and preserving --lock-immutability true when increasing retention. No automatic payload completion was introduced.
• Confirm preview API rollout for intended regions/clouds and obtain maintainer approval before release. This PR is open for review; maintainer and rollout approval remain required.

Testing Guide

Latest validation (2026-10-19, fc175e95ad): 53 unique STR tests passed, zero failures/errors/skips, including all five recorded scenarios and direct generated-inheritance coverage. Scoped flake8, customization pylint, package discovery, whitespace checks, and editor diagnostics passed. The complete 52-test published baseline also passed before refactoring. Hosted CI for this new commit is separate from older successful runs.

Prior local validation (2026-10-16): 50 tests passed, zero failures/errors/skips (34 CLI/HTTP unit tests + 11 scenario safety tests + 5 recorded scenarios). Offline execution used this checkout's CLI/core/test SDK source with the installed CLI libraries on Python 3.14.6, an empty Azure configuration, live-target flags removed, socket connections blocked, and only the unrelated release-update connectivity probe disabled.

The new original-resource final-GET regressions failed against the previous Location override and passed after the fix. A combined-suite run also exposed and fixed the unit-test session-cache isolation issue; the complete combined suite then passed in 70.238 seconds.

AAZ migration validation (2026-10-16)

• PASS: 50 offline tests, with actual socket connections blocked. Includes all five unchanged checked-in recordings from October 13; subsequent authorized live validation and its limitations are documented above.
• PASS: SQL AAZ command-model consistency, repository-configured flake8, and Python compilation of the generated/edited files.
• PASS: the compatibility adapter scores 10.00/10 under repository-configured pylint. The full legacy custom.py has 27 import-analysis diagnostics in this local SDK environment, all also present in the 31-diagnostic parent baseline; the migration adds zero pylint diagnostics. A clean full-module pylint result is not claimed.
• Additional coverage verifies MI --ids and required retention, lack of public registration for dropped-policy bases, nested systemData across all three generated resource types, and execution of all four generated examples through the public CLI wrappers.

Exact local validation commands and results

Run from the CLI worktree root. The installed SDK uses Python 3.14.6; the separate test dependencies are in E:\CLI\str-env.

# PASS: Ran 50 tests; failures=0, errors=0, skips=0.
@'
import os, sys, unittest, tempfile
from pathlib import Path
from unittest.mock import patch
root = Path.cwd()
sys.path[:0] = [str(root / 'src' / name) for name in ('azure-cli', 'azure-cli-core', 'azure-cli-testsdk')] + [r'E:\CLI\str-env\Lib\site-packages']
for key in list(os.environ):
    if key.startswith(('AZURE_CLI_TEST_SQL_', 'AZURE_TEST_')):
        os.environ.pop(key)
os.environ['AZURE_CORE_COLLECT_TELEMETRY'] = 'no'
with tempfile.TemporaryDirectory() as config, patch.dict(os.environ, {'AZURE_CONFIG_DIR': config}), patch('socket.socket.connect', side_effect=AssertionError('Offline test attempted network access')), patch('azure.cli.core.util.check_connectivity', return_value=False):
    suite = unittest.defaultTestLoader.loadTestsFromNames(['azure.cli.command_modules.sql.tests.latest.' + name for name in ('test_sql_str_policy', 'test_sql_db_str_policy', 'test_sql_mi_str_policy')])
    result = unittest.TextTestRunner(verbosity=2).run(suite)
print('SUMMARY tests={} failures={} errors={} skips={}'.format(result.testsRun, len(result.failures), len(result.errors), len(result.skipped)))
sys.exit(not result.wasSuccessful() or bool(result.skipped))
'@ | & 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe' -

# PASS: exit 0.
& 'E:\CLI\aaz-env\Scripts\aaz-dev.exe' command-model verify --aaz-path 'E:\CLI\aaz' --target sql

# PASS: exit 0.
& 'E:\CLI\aaz-env\Scripts\python.exe' -m flake8 --append-config '.flake8' 'src\azure-cli\azure\cli\command_modules\sql\operations\str_policy.py' 'src\azure-cli\azure\cli\command_modules\sql\custom.py' 'src\azure-cli\azure\cli\command_modules\sql\tests\latest\test_sql_str_policy.py'

# PASS: exit 0.
& 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe' -m compileall -q 'src\azure-cli\azure\cli\command_modules\sql\operations\str_policy.py' 'src\azure-cli\azure\cli\command_modules\sql\aaz\latest\sql\db' 'src\azure-cli\azure\cli\command_modules\sql\aaz\latest\sql\midb' 'src\azure-cli\azure\cli\command_modules\sql\custom.py' 'src\azure-cli\azure\cli\command_modules\sql\tests\latest\test_sql_str_policy.py'

# PASS: adapter pylint, exit 0, 10.00/10.
$env:PYTHONPATH='E:\CLI\azure-cli-str-immutability\src\azure-cli;E:\CLI\azure-cli-str-immutability\src\azure-cli-core;E:\CLI\azure-cli-str-immutability\src\azure-cli-testsdk;E:\CLI\str-env\Lib\site-packages;C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages'
& 'E:\CLI\aaz-env\Scripts\python.exe' -m pylint --rcfile 'pylintrc' --jobs 1 'src\azure-cli\azure\cli\command_modules\sql\operations\str_policy.py'

The broader AAZ repository check was stopped in favor of the focused SQL verification above. The regenerated head 03307dd24188df4fce24d1223c51430d19eb144f subsequently passed all 52 hosted checks. The October 19 cleanup commit requires separate CI.

SQL Database scenarios

Source: SQL Database STR tests.

Live-recorded scenario	HTTP interactions	Coverage and assertions
test_sql_db_short_term_retention	40	New randomized S0/Local DB after absence check. Retention/differential settings 7/24 → 6/12 → 5/12 → 5/24; explicit false sets 7 days without prompting. SET and independent GET assert retention/interval. No-wait sets 8 days, returns no output, and GET verifies 8/24. Tolerates unlocked Disabled/Enabled.
test_sql_db_short_term_retention_immutability	70	New DB; wait for Enabled; initialize 7/12. Decline/no-TTY cause no HTTP. Accepted confirmation locks at 7 days; SET returns Locked and GET independently verifies it. --yes increases to 8 days with SET and GET Locked. Explicit-lock decrease and false unlock return InvalidImmutableBackupRetentionPeriod and CannotRemoveLockedPitrImmutability. Differential-only no-wait preserves Locked at 8/24.
test_sql_db_existing_policy_immutability	14	Explicitly authorized disposable DB already Enabled. Locks with unchanged 7-day retention and preserves 24-hour differential interval; SET and GET report Locked. Rejects reduction to 6 days and unlocking. Repeated lock with no-wait has no output/prompt; independent GET remains Locked7/24. Policy-only transport guard; no create/delete.

All three refreshed SQL DB scenarios passed live on 2026-10-13 (new DBs in West US 2; policy-only in West Central US), and passed offline playback. The two new SQL DBs were retained by request. There are now eight retained SQL test databases across the earlier and current validation runs; they continue to incur charges. The policy-only run modifies only its expressly authorized retained test DB, not an original database.

SQL Managed Instance scenarios

Source: SQL MI STR tests.

Live-recorded scenario	HTTP interactions	Coverage and assertions
test_sql_managed_db_short_retention	46	New randomized DB on existing MI; live retention 7 → 14 → 7(false) → 10(no-wait). No confirmation for omitted/false lock. SET/GET retention checks; wait for backup readiness, then drop only its own DB. Dropped policy 10 → 7 → 6(no-wait). Both true and false lock flags with deleted-time fail locally without HTTP or prompt. Final policy GET after async SET also covers the timestamp-addressed dropped resource.
test_sql_managed_db_short_retention_immutability	53	New DB must report Enabled. Ordinary updates/false before locking; decline/no-TTY send no HTTP. Accepted lock at 7 and --yes increase to 8 both return SET Locked, with independent GET verification. Service rejects reduction/unlocking. After dropping only its own DB, policy remains Locked8; both dropped lock-flag values fail locally, and the service rejects dropped-retention reduction.

Both refreshed MI recordings passed live in West Central US on 2026-10-13 and offline playback. Earlier attempts encountered a non-JSON response and an interrupted backup-readiness wait; these are not counted as successful recordings and were superseded by complete passing captures. All MI test databases from these attempts were cleaned up, including failed-attempt databases. The seven original MI database names remain unchanged; locked dropped backups are not purged and remain for their retention period.

Offline regressions, audits and CI

• Current CLI/HTTP coverage: 34 tests (the original 28 plus six AAZ/integer-wire-type regressions). Original coverage: confirmation accept/decline/no-TTY/yes; omitted/false lock; request omission and integer/Boolean serialization; dropped-MI true/false rejection, zero retention, timestamp addressing; all three statuses; flattened output and nested systemData; required wait policy-name compatibility; IDs and help. Polling coverage includes async-only/both headers for all three resource types, InProgress → Succeeded → original policy GET, synchronous200, Location-only, no-wait request counts, Failed/Canceled without final read, final-GET403/404 propagation, and actual CLI SET JSON output. Lock-only serialization coverage does not imply live support.
• 13 scenario safety tests: the original six SQL DB and five MI safety tests, plus two shared cleanup regression methods covering both resource types, creation failures, absence checks and post-create output failures.
• Recording audit passed for all five captures: real target names/subscription IDs and credential markers absent; signed polling parameters redacted; unrelated dropped databases filtered. Every recorded completed async STR SET uses the policy GET, with five Locked SET results across the three locking scenarios. No STR OperationResults GET remains in these captures. No-wait SETs have no polling/final reads.
• Write-scope audit and post-run inventory/policy checks passed: prior database inventories preserved, only the two approved SQL DB additions remain, other retained test policies unchanged, and all MI attempt DBs removed. No server, MI or resource-group write is permitted by the guards; original databases are untouched.
• Targeted pycodestyle, git diff --check, and editor diagnostics passed. The shared STR operation module passed Pylint at 10.00/10. Full local SQL-module Pylint is not claimed because the installed runtime has compiled-only dependencies and previously reported unrelated findings.
• Hosted CI for prior head 03307dd24188df4fce24d1223c51430d19eb144f: 52/52 checks completed successfully, independently verified on 2026-10-19. Those results do not validate cleanup commit 48a4c88fac189658c1b07b896bd7ee376daf986c; current-head checks are pending.

Hosted pipeline history: The October 13 author-trigger permission failure was subsequently superseded by successful maintainer-triggered runs. The current customization-review commit needs its own CI; no older pending/green status should be treated as its result.

Replay with python -m unittest azure.cli.command_modules.sql.tests.latest.test_sql_str_policy azure.cli.command_modules.sql.tests.latest.test_sql_mi_str_policy azure.cli.command_modules.sql.tests.latest.test_sql_db_str_policy in a configured developer checkout.

Live recording requirements and safety guards: SQL STR recording guidance.

• MI: AZURE_CLI_TEST_SQL_MI_RESOURCE_ID; irreversible locking additionally requires AZURE_CLI_TEST_SQL_MI_ALLOW_IMMUTABILITY_LOCK=true.
• New SQL DB: AZURE_CLI_TEST_SQL_SERVER_RESOURCE_ID; locking additionally requires AZURE_CLI_TEST_SQL_DB_ALLOW_IMMUTABILITY_LOCK=true. These runs used AZURE_CLI_TEST_SQL_DB_KEEP_DATABASES=true.
• Policy-only SQL DB: AZURE_CLI_TEST_SQL_DB_RESOURCE_ID plus separate irreversible-lock authorization. Requires Enabled and retention above one day; always retains the database.
• Missing recordings do not authorize live access. Do not run the entire SQL module live on shared resources. Local diagnostic cassettes are excluded from this PR.

History Notes

[SQL] az sql db str-policy: Add short-term backup immutability locking with confirmation and expose immutability status
[SQL] az sql midb short-term-retention-policy: Add immutability locking for live databases and expose status for live and dropped databases

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR title and description has followed the guideline in Submitting Pull Requests.
• I adhere to the Command Guidelines.
• I adhere to the Error Handling Guidelines.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Yong Zhang (yonzhan)]

Please fix CI issues

[svmicano]

Production MI validation — 2026-10-12

Validated commit 3fe125128615c9c7a7958520ccb10a970fa9be22 by running the edited CLI/core source against the public Azure production ARM endpoint in West Europe. Two new, uniquely named databases were created on an existing test MI. No MI-level write requests were made, and pre-existing databases were not modified.

Check	Result
Preview STR show for both live databases	Passed; retentionDays: 7, immutabilityStatus: Disabled initially
Synchronous retention update with lock flag omitted	Passed on both databases: 7 → 14 days, verified by show
Explicit --lock-immutability false without --yes	Passed without prompting: 14 → 7 days
Live --no-wait	Passed: update returned without a result, then read-only polling/show confirmed 10 days
Declined confirmation / no-TTY safeguards	Passed using a controlled prompt host: exit 1, no result, zero HTTP requests; live readback was unchanged
Authorized --lock-immutability true --yes	Service rejected with LockPitrImmutabilityNotAllowed; readback remained Disabled, with retention unchanged
Dropped database STR show	Passed after confirming backup readiness and dropping only a new test database
Dropped STR synchronous update	Passed: 10 → 7 days, verified by show
Dropped STR --no-wait	Passed: 7 → 6 days, verified by read-only polling/show
Dropped --lock-immutability true and false	Both rejected locally: exit 1, no result, zero HTTP requests, no prompt
Cleanup / scope safety	Both newly created databases deleted; MI configuration matched the initial baseline, and the two original databases remained online

The dropped test backups remain under their configured retention; they were not purged. Use the original textual deletionDate from az sql midb list-deleted (for example with --query ... --output tsv) so shell date conversion does not lose fractional seconds.

Still blocked: this MI reports immutability Disabled, and the service explicitly disallows locking. Successful locking, Locked readback and rejection of retention decreases after locking therefore remain unvalidated on live resources. No MI configuration was changed to work around this limitation. SQL Database (non-MI) live validation was not performed in this run.

These were live smoke checks, not newly captured/re-recorded scenario cassettes. Existing recording refresh and standard full-module validation remain outstanding; keep this PR in draft. No implementation changes were required by the supported-path checks.

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[svmicano]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 34207 in repo Azure/azure-cli

[microsoft-github-policy-service]

🔔 Routing this PR to @Azure/act-observability-squad.

[microsoft-github-policy-service]

🔔 Routing this PR to @Azure/act-codegen-extensibility-squad.

[JaysonTaiMicrosoft]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[x-engineering-agent]

X Engineering Agent Report

Review — Comments

svmicano

SQL STR review

CI passed (52 checks), with no confirmed semantic defect across the eight review lenses. Issue-scenario regression coverage remains unverified; this is an evidence limitation, not a demonstrated code defect.

The custom wrappers preserve conditional irreversible-action confirmation, reject either lock value for dropped MI databases before HTTP, and omit unspecified settings. The generated-command adapters preserve integer differential-interval requests and use the final policy resource for async SET output. Focused tests exercise cancellation, request omission, polling failures, flattened status output, nested systemData, IDs and wait compatibility. No unresolved Copilot feedback was supplied.

Test validation

• Agent live test: Not run; this is a review-only PR. Check author-provided test evidence and upstream CI separately.
• Regression coverage: For sql: 4 focused test file(s) and 5 recording file(s) changed. Scenario coverage is unverified; review the issue's required conditions, test setup, and assertions before approval. No linked issue was found in the PR timeline; inspect the source issue and its required scenario manually.

There is no module-level coverage gap. The author reports 53 offline tests and later live integer-interval checks; those are author evidence, distinct from this review and upstream CI. The five October 13 recordings exercise preview requests, successful async SET followed by policy GET, locking, rejection paths and live/dropped MI behavior. They predate the integer-serialization correction and latest adapter refactor; recordings alone do not establish execution of the current adapter. Preview API availability beyond the recorded regions/cloud remains unverified, as already noted in the PR.

Before merge, attach or identify head-pinned focused regression results for c6393982b77aebc6f3bfe74db72ecc6da0148d7c, replaying the following tests and existing recordings. In particular, verify actual JSON integer tokens for 12/24-hour updates, omitted retention on differential-only requests, locked differential-only no-wait behavior, and final SET status/error propagation. This requests regression evidence, not unrelated source changes or a new irreversible live lock.

Paths below are relative to src/azure-cli/azure/cli/command_modules/sql/tests/latest/:

• Tests: test_sql_str_policy.py, test_sql_db_str_policy.py, test_sql_mi_str_policy.py.
• SQL DB recordings: recordings/test_sql_db_short_term_retention.yaml, recordings/test_sql_db_short_term_retention_immutability.yaml, recordings/test_sql_db_existing_policy_immutability.yaml.
• MI recordings: recordings/test_sql_managed_db_short_retention.yaml, recordings/test_sql_managed_db_short_retention_immutability.yaml.

Focused replay in a configured developer checkout, with live-target flags unset:

python -m unittest azure.cli.command_modules.sql.tests.latest.test_sql_str_policy azure.cli.command_modules.sql.tests.latest.test_sql_db_str_policy azure.cli.command_modules.sql.tests.latest.test_sql_mi_str_policy

Risk assessment — 55/100 · High

The High rating is driven by public CLI behavior, failure-handling behavior, generated output.

• Change scope: 32 changed files, 39081 changed lines (+12875 / -26206), including 22 production files.
• Affected components: sql
• Risk drivers: public CLI behavior (+18); failure-handling behavior (+12); generated output (+12)
• Regression evidence: Changed regression tests are included, reducing risk.
• Confidence: High because changed-line patches were available for every production file.
• Required review: Owning-squad review is recommended for sql before merge.

Posted by x-engineering-agent (Reviewer)

[microsoft-github-policy-service]

🔔 Routing this PR to @Azure/act-observability-squad.

[microsoft-github-policy-service]

🔔 Routing this PR to @Azure/act-codegen-extensibility-squad.

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[x-engineering-agent]

svmicano

Review outcome

One confirmed test-resource cleanup defect remains at 03307dd24188df4fce24d1223c51430d19eb144f. No production defect was confirmed in the bounded STR mapping review. COMMENT only; not approval or merge readiness.

Confirmed semantic finding

P2 — Mark the managed database as owned before checking create output.
src/azure-cli/azure/cli/command_modules/sql/tests/latest/test_sql_mi_str_policy.py:135-137 passes name/status checks into self.cmd(...) before setting database_created=True. src/azure-cli-testsdk/azure/cli/testsdk/base.py:175-177,268-278 executes checks before returning. If creation succeeds but an assertion fails, cleanup at lines 140-144 sees false and leaves a billable database behind. This confirms the existing Copilot comment. Separate creation from checks, set ownership immediately after successful creation, then assert output. Verify with a mocked successful create/failing assertion that registered cleanup deletes once; a failed create must not authorize deletion. No feedback-dismissal, dispatch or source change was performed.

Upstream CI succeeded

Already-read snapshot: 52/52 completed and passed; 0 failed, pending or cancelled validations. Latest completion: 2026-10-16T17:35:55Z. CI was not re-polled. Required scenario regression remains unverified; no Agent tests or live validation ran.

Request, response and scenario evidence

• _str_policy.py:20-25,45-59 drops only omitted (None) arguments, retaining false/zero and defaulting the policy name. The DB adapter emits integer differential intervals without inserting omitted settings. Generated DB/MI PUT schemas map properties.retentionDays and properties.lockImmutability; DB also maps diffBackupIntervalInHours. Immutable-backup state is returned as immutabilityStatus (Disabled/Enabled/Locked), not an immutableBackups request field. GET/SET output flattens policy properties.
• Custom handlers confirm only true locking and reject either lock value for dropped MI databases before HTTP. Polling preserves the final policy GET; no status is synthesized.
• DB tests wait for Enabled; MI locking asserts Enabled. Both assert SET output and independent GET state after locking/increasing retention, then rejected decreases/unlocking with preserved Locked state. The recordings show matching payloads and Enabled-to-Locked responses, not merely setup/URI evidence: DB immutability cassette lines 2584/2759 and MI lines 792/917 show lock requests and Locked responses. Omission/false and no-wait have separate assertions. DB lock-only service success is explicitly NOT proved; those scenarios include retention.
• Metadata identifies upstream AAZ model PR #1130; the tests README describes generation from 2026-08-01-preview plus compatibility adapters. This supports provenance, not independent regeneration verification.

Focused verification targets (not run)

Tests:

• src/azure-cli/azure/cli/command_modules/sql/tests/latest/test_sql_commands.py
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/test_sql_str_policy.py
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/test_sql_db_str_policy.py
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/test_sql_mi_str_policy.py
  Recordings:
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/recordings/test_sql_db_existing_policy_immutability.yaml
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/recordings/test_sql_db_short_term_retention.yaml
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/recordings/test_sql_db_short_term_retention_immutability.yaml
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/recordings/test_sql_managed_db_short_retention.yaml
• src/azure-cli/azure/cli/command_modules/sql/tests/latest/recordings/test_sql_managed_db_short_retention_immutability.yaml
  After fixing cleanup, rerun focused offline STR adapter/safety tests and these five scenario playbacks. Map required conditions to setup and returned-output assertions before approval; changed files/recordings alone are not coverage all-clear.

Test validation

• Agent live test: Not run; this is a review-only PR. Check author-provided test evidence and upstream CI separately.
• Regression coverage: For sql: 4 focused test file(s) and 5 recording file(s) changed. Scenario coverage is unverified; review the issue's required conditions, test setup, and assertions before approval. No linked issue was found in the PR timeline; inspect the source issue and its required scenario manually.

Risk assessment

83/100 · Critical

The Critical rating is driven by security-sensitive behavior, public CLI behavior, failure-handling behavior and 1 additional signal(s).

• Change scope: 31 changed files, 38940 changed lines (+12734 / -26206), including 21 production files.
• Affected components: sql
• Risk drivers: security-sensitive behavior (+28); public CLI behavior (+18); failure-handling behavior (+12); generated output (+12)
• Regression evidence: Changed regression tests are included, reducing risk.
• Confidence: High because changed-line patches were available for every production file.
• Required review: Owning-squad review is required for sql before merge.

Posted by x-engineering-agent (Reviewer)

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).