[Automated] Update az CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to az CLI options classes.

The generator scraped the latest CLI help output from the installed tool.

Changes

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	✅ 0 (≤ 20 complexity)

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code Review: PR #2535 — [Automated] Update az CLI Options

Summary

This is an automated PR generated by the ModularPipelines.OptionsGenerator tool, scraping the Azure CLI (az) help output to keep options classes current. The diff consists of exactly two changes:

1. AssemblyInfo.Generated.cs — Generation timestamp updated (weekly scheduled run).
2. AzMysqlFlexibleServerRestoreOptions.Generated.cs — The /// <summary> comment on RestoreTime has its Default: value updated to reflect the current generation time.

The solution builds successfully per the workflow.

---

What's Working Well

The automated pipeline design is sound. Weekly scheduling, matrix strategy per tool, build verification before creating a PR, and auto-merge with squash are all good patterns for keeping generated code up to date without human toil.

The [ExcludeFromCodeCoverage] and <auto-generated> headers on all generated files correctly signal to both humans and tooling that these files shouldn't be hand-edited or measured for coverage.

The ManualOverrideDetector (priority 0) pattern is well-thought-out — it gives maintainers a stable escape hatch via TypeOverrides/az.json when the heuristic or live scraping gets a type wrong, without having to modify generator logic.

---

Issues and Concerns

1. RestoreTime has the wrong C# type — a pre-existing generator bug surfaced by this PR

The --restore-time flag accepts an ISO 8601 datetime string, yet the generated property is:

[CliFlag("--restore-time")]
public bool? RestoreTime { get; set; }

bool? is semantically wrong here. Setting RestoreTime = true cannot communicate a point-in-time to the CLI — at best it would pass the flag with no value (producing an error), at worst it is silently ignored. The correct type is string? (or DateTimeOffset? if the framework serializes it correctly).

The same issue exists in related options classes:

• AzPostgresFlexibleServerRestoreOptions.Generated.cs — RestoreTime is bool?
• AzPostgresFlexibleServerGeoRestoreOptions.Generated.cs — RestoreTime is bool?
• Several --restore-timestamp options in CosmosDB commands are also bool?

Recommendation: Add manual override entries to tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/TypeOverrides/az.json to fix this class of options permanently:

"mysql.flexible-server.restore": {
  "--restore-time": {
    "type": "string",
    "reason": "ISO8601 datetime string for point-in-time restore"
  }
},
"postgres.flexible-server.restore": {
  "--restore-time": {
    "type": "string",
    "reason": "ISO8601 datetime string for point-in-time restore"
  }
}

Alternatively, a broader fix in HeuristicTypeDetector could add option names ending in -time or -timestamp to a list of StringNamePatterns, preventing them from ever being inferred as bool. Why this matters: this is a functional correctness bug — library users who need to restore a database to a specific point in time literally cannot do so through the generated type-safe API.

2. Volatile Default: <timestamp> in XML doc comments creates noise every weekly run

The XML doc for RestoreTime now reads:

The point in time in UTC to restore from (ISO8601 format), e.g., 2017-04-26T02:10:00+00:00.
The default value is set to current time.  Default: 2026-04-26T03:26:32+00:00.

The Default: 2026-04-26T03:26:32+00:00 suffix comes from the Azure CLI help output at generation time and changes on every weekly run — producing a guaranteed cosmetic diff with no functional value to consumers. A developer reading IntelliSense already has the informative text: "The default value is set to current time."

The generator should strip volatile Default: <iso8601-timestamp> suffixes from descriptions before writing XML doc comments. A regex like \s+Default:\s+\d{4}-\d{2}-\d{2}T[\d:+Z.-]+ in the description cleanup step (the scraper or OptionTypeEnhancer) would solve this.

Why this matters: without the fix, every weekly PR touching Azure flexible-server restore commands will have a one-line XML comment diff that adds zero value and inflates the PR history.

---

Overall Verdict

This PR is safe to merge — the actual functional content is unchanged. However, it surfaces two pre-existing generator issues worth addressing before the next weekly run:

1. --restore-time and similar datetime options are generated as bool? instead of string? — a functional correctness bug that breaks the type-safe API for point-in-time restore scenarios.
2. Volatile Default: <timestamp> values in XML doc comments — each weekly run will always produce at least one noisy diff line for no consumer benefit.