Progress - Complete the bars of 9 more commands in finally blocks (tier 2)

[andreasjordan]

Part of RFC #10548: the try/finally leak fixes, tier 2 of 3. Same pattern as #10773 (tier 1), one commit per command with its test. Independent of #10773.

Problem

These 9 commands complete their progress bar only on the success path, so a throw under -EnableException, a stopped pipeline (Ctrl+C) or Select-Object -First left the bar on screen for the rest of the session. Two of them were worse:

• Expand-DbaDbLogFile never completed its bars at all, not even after a run that worked: the bar of the databases (Id 1) and the bar of the growth (Id 2) stayed after every run. Its only completion completed the bar of the databases when a log backup failed, which removed the parent while the child stayed.
• Invoke-DbaDiagnosticQuery drew its bar in process and completed it in end, which neither Select-Object -First nor a stopped pipeline reaches.

Change

Each bar's completion moves into a finally around that bar's lifetime.

• Invoke-DbaAdvancedRestore has a parent bar per database (Id 1) and a child bar per backup file (Id 2). The child is now completed first thing in the existing finally of each file's restore, before the output there (a downstream Select-Object -First stops at that output). The loop over the files runs in try/finally, whose finally completes the parent. The success-path completion of the child stays, because a stop-at-mark restore still runs the recovery statement after it.
• Expand-DbaDbLogFile: the growth loop, the log backup and the loop over the databases each run in try/finally, each finally completes its own bar, children inside their parent. The completion of the parent on a failed backup goes away. The completion of the backup bar after the backup stays, because the shrink follows it.
• Invoke-DbaDiagnosticQuery: the loop over the instances runs in try/finally. Its counter restarts per instance, so the bar's lifetime is that loop. The end block held only the completion and goes away.
• Read-DbaBackupHeader, Start-DbaMigration, Sync-DbaAvailabilityGroup, Export-DbaUser, Invoke-DbaDbDataGenerator, Invoke-DbaDbPiiScan: one try/finally around the loop or the steps that draw the bar.

Most of the diff is re-indentation: git diff -w shows 38 lines added and 5 removed for the 9 commands.

Test

Same boundary as in #10773: the real command runs in a runspace of its own, created by the PowerShell API without a host, where Write-Progress puts every record into Streams.Progress. The test asserts that the command drew its bar and that no progress Id is left whose last record is not a completed one.

Command	How the test ends the run
Invoke-DbaAdvancedRestore	full and log backup, Select-Object -First 1 stops after the full backup (asserted)
Invoke-DbaDiagnosticQuery	one query, Select-Object -First 1 at its result
Start-DbaMigration	-WhatIf, pipeline stopped at the first migration step
Sync-DbaAvailabilityGroup	the existing job sync between two instances with -WhatIf, pipeline stopped at the first step
Export-DbaUser	-Passthru, Select-Object -First 1 at the script
Invoke-DbaDbDataGenerator	Select-Object -First 1 at the result of the table
Invoke-DbaDbPiiScan	pipeline stopped at the first scan record; a second, unskipped Describe with its own small database, because the existing integration Describe is skipped as a whole
Expand-DbaDbLogFile	a plain run that grows the log once more; both bars must be completed
Read-DbaBackupHeader	no automated test, see below

Read-DbaBackupHeader runs its threads in a runspace pool on $Host, and once a thread has run there, the warning, verbose and progress records of the calling pipeline no longer reach the Streams of an API host, so its bar cannot be seen this way (same as the -Parallel bar of Start-DbaDbEncryption in #10773). I checked it in a real console window instead, reading the ConsoleHost's pending bars by reflection after Read-DbaBackupHeader ... | Select-Object -First 1: the old command leaves "Updating" (Id 1) behind on 5.1 and 7.6, the new one does not. Its existing tests pass.

Results (lab, InstanceSingle SQL Server 2019, Copy1 2022, Copy2 2025):

• New command: all 9 test files pass on PowerShell 5.1 and 7.6, without warnings.
• Old command: in every file with a new test exactly that test fails, on both editions. Expand-DbaDbLogFile leaves both Ids open.
• TestTestfiles.Tests.ps1 and TestTestLayout.ps1 report nothing for the 8 changed test files.

Left open

• Sync-DbaAvailabilityGroup closes the dedicated admin connection it opens for the passwords only on the success path, so a throw or a stop between opening and closing keeps the single DAC of the instance busy. Not a progress defect, not changed here.
• Read-DbaBackupHeader does not close its runspace pool or restore [Runspace]::DefaultRunspace when it is stopped. Same.

🤖 Generated with Claude Code

[potatoqualitee]

Reviewed at 8a05b63.

The progress cleanup scopes cover the relevant returns, exceptions, continuation paths, multiple-input paths, and early pipeline termination without changing the commands' existing work or loop targets. In particular, the restore child bar completes before its result is emitted, and log expansion completes nested bars before the database bar. Reviewed all 17 changed files, surrounding source and flow-control helpers, tests, CI, and existing discussions.

The eight new regression-test sections exercise real commands and verify that the relevant progress appeared and was subsequently completed. The ci-azure logs show all nine relevant command test files passing at this head; checks show 20 successes and one skipped legacy windows-tests job. Read-DbaBackupHeader's cancellation verification remains manual as documented. I did not rerun the SQL integration suite or that manual console test locally.

No material blocking defect found.