Copy-DbaDatabase - Stop eating the caller loop when a system database is requested

[andreasjordan]

Part of #10638, the sweep for Stop-Function -Continue outside an enclosing loop. Same shape and same test as #10637.

Problem

Copy-DbaDatabase refuses system databases with Stop-Function -Continue in its process block (Copy-DbaDatabase.ps1:777). No loop encloses that site inside the command, so without -EnableException the continue unwinds out of the command and consumes an iteration of whatever loop the caller runs in. Proven in the lab with the plain-script recipe: three calls with -Database master in a foreach left the loop counter at 0 on development and at 3 with the fix.

What changed

The -Continue is dropped and an explicit return ends the process block for that input, as in #10637. Nothing else changes; the check still fires before any connection is made.

Tests

New context When a system database is requested: three calls in a loop, asserting the loop count and the warning. Through the testing-dbatools harness: green on both editions with the fix (28 passed); the plain-script proof above is the red-on-old.

created by Claude and reviewed by Andreas Jordan

🤖 Generated with Claude Code

[potatoqualitee]

public/Copy-DbaDatabase.ps1:779-780 still suppresses valid later pipeline inputs after one unsupported system database. Stop-Function without -Continue sets the command-scope interrupt flag; the explicit return ends only the current process invocation, and the next piped database is then rejected by Test-FunctionInterrupt at lines 729-731. For example, piping master followed by an application database warns for master and silently skips the application database. The new test calls the command three separate times, so it does not exercise this single-pipeline path.

Please preserve the warning/error behavior without leaving the command-wide interrupt flag set for this per-input rejection, and add a regression test with a system database followed by a valid database in one pipeline.

[andreasjordan]

Confirmed and fixed in 2ecac8b: the plain Stop-Function set the function-scope interrupt variable, so after one system database Test-FunctionInterrupt dropped every database piped in after it.

What changed: the system-database check now throws under -EnableException and otherwise warns and returns from that process invocation only, so the flag is never set for this per-input rejection. -Continue is not an option here: no loop encloses the check in the process block, and the escaping continue was the original #10638 defect.

Tests: the context gained a fixture database on InstanceCopy1 and two tests. master followed by that database in one pipeline copies the database (one result, Successful) and warns for master; the -EnableException form throws the same message. Through the testing-dbatools harness: the file is green on both editions (31/31); against the reviewed head, the pipeline test fails with zero results (the second database is dropped) while the throw test passes there too, as the old code threw as well.

created by Claude and reviewed by Andreas Jordan

[potatoqualitee]

The current head resolves my previous pipeline-control-flow finding, including coverage that a valid database following a system database is still processed. No material defects remain. Reviewed at head 2ecac8b.

[potatoqualitee]

I'm not so sure this makes sense. it'll show duplicate if the person has enableexception enabled it'll warn them twice.

[andreasjordan]

It never warned twice, but I agree the shape suggested it could: under -EnableException, Stop-Function throws before the next line is reached, so the Write-Message after it was dead code on that path. Fixed in c3d4df0 by making it an explicit if/else.

Measured on the lab, pwsh and 5.1: the exception path emits the exception and one warning record (the one Stop-Function itself writes before every throw in dbatools; a console shows only the exception), the warning path emits exactly one warning. Both are asserted now: the throw test runs the command in the test scope with its own warning variable and checks one record, the loop test checks that the last rejected call warned once. The whole file is green on both editions (31/31).

created by Claude and reviewed by Andreas Jordan

want changes

[potatoqualitee]

No material defects found.

[potatoqualitee]

ty 🙇🏼