planview analyze returns a hollow parse for exec <procedure> plans (exit 0, empty stderr)

[samplesty]

Version

planview 1.19.1+5bcfdaaca1a7485bf5692fd2d40dc4a6e793393e

What happens

Given an estimated plan captured with SET SHOWPLAN_XML ON around an EXEC <procedure> for a large stored procedure (~3,000 lines, many statements), planview analyze exits 0 with empty stderr and reports:

total_statements:    1
max_estimated_cost:  0
total_warnings:      0

The plan file itself contains rather more than that:

File size	4.2 MB
StmtSimple elements	184
...of which carry a QueryPlan	87
StmtCond elements	29
NonParallelPlanReason	present, non-empty
Sum of StatementSubTreeCost	691.3

So the parse never descends into the procedure body. --output text and --output json --warnings-only behave the same way on the same file, so it does not look specific to operator-tree serialization.

Why it is worth fixing rather than documenting

The failure mode is silent and produces a well-formed, plausible result. Nothing about the output suggests it is empty because the parse stopped early — it looks exactly like a clean plan with no warnings and negligible cost. That invites reporting "no warnings found" and "cost is negligible" from a plan that in fact carries 87 statement plans and a summed cost of 691.

For contrast, analyze does descend correctly into StmtCond (IF/WHILE) bodies in a plain batch, so the gap appears specific to plans wrapping a procedure call.

Expected

Either descend into the procedure body, or fail loudly. A non-zero exit, or a warning that the plan contains statements the parse could not reach, would both be fine — the problem is that a caller cannot distinguish "no findings" from "found nothing because it did not look".

Suggested detection

A cheap invariant: compare the number of XML statements carrying a QueryPlan against summary.total_statements, and treat a large plan reporting max_estimated_cost: 0 with zero warnings as suspect. That combination reliably indicates the parse did not reach the real statements.

Notes

Happy to attach a sanitised plan file if that helps — the original is against a production schema so it would need scrubbing first. Also glad to test a fix against the same plan.

Thanks for the tool; the Query Store filters and the token-efficient JSON output are genuinely useful, which is why this particular silent failure stood out.

[erikdarlingdata]

Fixed in #456, merged to dev. Good report — the file statistics and the StmtCond-works-but-this-doesn't contrast are what made it quick to place.

I reproduced it before touching anything: SQL Server 2025, a four-statement procedure, SET SHOWPLAN_XML ON around the EXEC. Six StmtSimple, four carrying a QueryPlan, summed cost 1.88 — and analyze reported 1 statement, 0 warnings, cost 0. Exactly your numbers at a smaller scale, and it repros on 1.21.0 as well as your 1.19.1.

One correction to the diagnosis, because it changes the fix. The parse does descend into procedures — ShowPlanParser has always read StoredProc sub-plans. That code just sits below an early return taken when a statement carries no QueryPlan of its own:

if (queryPlanEl == null)
{
    stmt.RootNode = new PlanNode { ... };   // synthetic node for DECLARE/ASSIGN and friends
    return stmt;                            // never reaches the StoredProc block 70 lines down
}

An EXEC statement is exactly that: no plan of its own, because every plan lives in the body. So the descent existed and was unreachable in the one case it was written for. That is also why StmtCond worked — an IF in a plain batch reaches the recursive path further up, well before that return. Same latent problem applied to a UDF call whose calling statement carries no plan.

Sub-plan parsing now happens above that early return. Your plan should go from 1 statement to all 87.

Three consumers had the same blind spot and now share one traversal: the analyzer (so no rule ever ran on a procedure body), the result mapper (where your total_statements: 1 and max_estimated_cost: 0 came from), and — the uncomfortable one — the test helper behind our characterization suite. The golden master and the analyzer were both walking batch.Statements, so no number of committed procedure plans could have caught this. A test that cannot see what the code cannot see is not covering it.

Worth noting the traversal was never actually missing: the complexity limiter has always descended correctly, so it was counting statements the analysis never analyzed.

On your suggested invariant — comparing XML statements-with-a-QueryPlan against summary.total_statements — it is a good instinct and I did not implement it. With the specific cause fixed it would mostly fire on plans that are legitimately trivial, and a heuristic that cries wolf gets ignored. The structural version is what I did instead: the analyzer and the golden master now share one traversal, so they cannot silently diverge again. If a second silent-empty cause turns up, I will revisit that.

I would like to take you up on the offer to test against the real plan. Mine is a small constructed case; yours has 87 statement plans, 29 StmtCond, and 4.2 MB of nesting that mine does not exercise. No need to scrub it for me — just run the dev build against it and tell me whether total_statements and the summed cost line up with what you counted in the XML. If they do not, the remaining gap is something my fixture does not reach and I want to see it.

Thanks for the kind words about the Query Store filters and the JSON output, and for writing this up as carefully as you did.