Add Multiple Servers: bulk paste-a-list onboarding with shared credentials (both apps)

[erikdarlingdata]

Problem

Adding a monitoring estate one server at a time is the onboarding wall: a 40-box fleet meant opening the single Add-Server dialog forty times and re-typing the same SQL login into every one. Both apps needed a way to paste a list and add it all at once — with the shared credential entered a single time, not forty.

Design

An "Add Multiple Servers" button beside Add Server in both Lite and the Darling viewer opens a paste-a-list dialog.

• Shared grammar — a new PerformanceMonitor.Common.BulkServerListParser parses server[, display name][, database] per line: comma- or tab-separated (tab wins when present, so a spreadsheet paste keeps commas inside a field), trimmed, trailing empty fields dropped (Excel's trailing cells), # comments and blank lines skipped with line numbers still correct, and empty-server / too-many-fields reported as per-line errors rather than silently dropped. Pure and synchronous; the parser does no dedupe or normalization (both are app-side by design). A mirrored test file in both suites pins the grammar so the two apps can't drift.
• One secret, never N — the shared auth block is entered once. Lite mints a single auto-named CredentialProfile (unique-suffixed on a name clash) that every added row references, created only when at least one new row survives dedupe (a fully-duplicate paste leaves no orphan profile). Darling has no store-side profile table, so it resolves the shared credential once to a single DPAPI-LocalMachine blob — ViewerServerSecret.Protect called exactly once — and stamps that same blob onto every server row and every test_connect probe. No plaintext credential is ever written.
• Duplicates skipped, not silently merged — both apps gate candidates through the ratified HashSet<string>(OrdinalIgnoreCase) over the shared ServerIdHelper.BuildStorageName(name, db, readOnlyIntent) identity, seeded from existing servers' real keys and derived from the built row (one composition feeds the gate and the stored server_id). Case-folding is the point: an existing SQL01 skips a pasted sql01 even though their raw hashes differ, while a per-database Azure entry and a read-only-intent connection stay distinct. A blank database maps to NULL, never master — coercing it would mint a mismatched identity and split a server's collected data from its single-added twin.
• Test All is informational only (no server is added) and honest per app: Lite probes directly, so it runs up to 8 in parallel, cancellable, with each probe catching every error internally (an escaping OperationCanceledException on Cancel would crash the app — the never-faulting probe structure forbids it) and honoring the configured connection timeout. Darling routes probes through the service's test_connect command, and because the service drains its queue serially, Test All is a sequential sweep with live per-row status and a Cancel that stops between rows — the in-flight probe finishes and self-deletes its credential-bearing command row, so no orphaned rows and no parallelism theater.
• Entra MFA is excluded from bulk in both apps (an interactive popup per server is a popup storm at first collection), and a defensive belt in each app's row-mapping helper rejects any resolved un-honorable auth at the single choke point feeding both Test All and Add — so it can't leak in through a hand-edited profile.

Add writes every valid non-duplicate row (per-row failures reported, batch continues), returns an added / skipped / failed summary, and does not auto-connect (the background collector picks new rows up on its next cycle).

Parity

Both apps get the same feature from the same shared parser and the same dedupe identity. The two documented asymmetries are intentional and match each app's architecture: Lite mints one shared credential profile while Darling stamps one shared DPAPI blob (the store has no profile concept), and Lite's Test All is genuinely parallel while Darling's is sequential (the service drains commands serially, so viewer-side parallelism would be theater). The single Add-Server dialog is not edited in either app (it remains the MFA path and keeps the per-server niceties bulk omits), and the deprecated Full Dashboard is untouched.

Test results

• dotnet build (Debug): Lite 0 errors, Darling viewer 0 errors.
• Full Lite.Tests: 1352 passed, 0 failed (incl. the mirrored parser cases, the BuildServerConnection mapping + dedupe-gate pins, and ThemeCompletenessTests 2/2).
• Full Darling.Tests: 2148 passed, 134 skipped (live-Postgres-gated), 0 failed (incl. the mirrored parser cases, the BuildMonitoredServerRow / BuildTestConnectServer mapping + dedupe-gate pins, and ThemeCompletenessTests 2/2).
• No capability-pin baselines changed (the ServerTab no-DataGridFilterManager scan and the plan-viewer ratchet stay green).
• EOL check: git diff --ignore-cr-at-eol --name-only (6) equals git diff --name-only (6); the 8-file gap to git status --short (14) is exactly the new untracked files.

🤖 Generated with Claude Code