Give querystore the depth ceiling that analyze got (#430)

[erikdarlingdata]

Completes #430. The crash fix in #431 was right; its enumeration of call sites was one file short.

What was missed

#431 made the depth ceiling a shared constant and referenced it from every serializer it found: both Robot Advice entry points, the MCP tool options, and AnalyzeCommand's two option sets. QueryStoreCommand builds its own JsonOptions and CompactJsonOptions, identical in shape to AnalyzeCommand's, and neither ever got MaxDepth.

So planview querystore has kept failing on any plan deeper than roughly 30 operators for as long as analyze has been fine.

Why nobody reported it

It fails quietly. The per-plan try/catch in the sweep loop turns the JsonException into one ERROR: ... row in summary.txt and moves on to the next plan — so a sweep over a few hundred Query Store plans silently analyzes all but the deep ones. Query Store batch analysis is exactly where the deep plans are.

Why the fix isn't just two more MaxDepth = lines

A shared constant only helps the call sites that remember to reference it, and the options were still duplicated per command. Editing AnalyzeCommand's two sets did nothing for the identical pair one file over, and nothing anywhere said they were supposed to match.

The options now live on AnalysisJson next to the constant — IndentedWithoutNulls and CompactWithoutNulls — and both commands point at them. There is no longer a copy to forget.

Values are unchanged for analyze: same WriteIndented, same JsonIgnoreCondition.WhenWritingNull, same ceiling. Only querystore behaviour changes, and only from "fails on deep plans" to "doesn't".

Test

It walks the options rather than trusting the call sites, since trusting them is what went wrong: every static JsonSerializerOptions on a *Command type in PlanViewer.Cli must carry the ceiling.

Verified by reverting just the QueryStoreCommand hunk, at which point it fails naming both offenders:

These write an analysis with the default depth ceiling and will fail on a deep plan:
QueryStoreCommand.JsonOptions (MaxDepth 0), QueryStoreCommand.CompactJsonOptions (MaxDepth 0)

A new command that rolls its own now fails here rather than in someone's Query Store sweep.

82 tests across AnalysisJsonDepthTests and the CLI/analysis classes, 0 failures. dotnet build clean.

🤖 Generated with Claude Code

[claude]

Reviewed. This is a tight, well-scoped fix.

• Verified the claim in the description: grepped for every JsonSerializerOptions construction under src/ — AnalyzeCommand, QueryStoreCommand, MainWindow.PlanViewer.cs, QuerySessionControl.Advice.cs, and McpHelpers.cs all now route through AnalysisJson's shared instances/constant. No other command builds its own analysis-writing options, so this closes out the [BUG] Robot Advice crashes the app #430 enumeration.
• IndentedWithoutNulls/CompactWithoutNulls preserve the exact prior shape for both commands (WriteIndented only where it was set before, same DefaultIgnoreCondition), so this is depth-ceiling-only behavior change for querystore, as claimed.
• The reflection-based regression test is a good structural guard against this exact class of regression (new *Command rolling its own options). One narrow gap worth knowing about: it only catches static fields named to look for JsonSerializerOptions on types ending in Command — an inline new JsonSerializerOptions{...} passed directly into a Serialize call (never assigned to a field) would slip past it. Not a blocker; just noting the boundary of the guard for future changes in this file.
• No untrusted-input, T-SQL, versioning, or Blazor-linked-file concerns apply here — no SQL generation or PlanViewer.Core additions in this diff.

No issues found.