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