fix: honour Spanner emulator detection in outbox/inbox connections (#4162)

[iancooper]

Symptom

Run against the Spanner emulator, 60 Spanner Outbox/Inbox tests failed at fixture setup with:

System.InvalidOperationException : Your default credentials were not found.

The gRPC client tried to load Application Default Credentials instead of routing to SPANNER_EMULATOR_HOST. The 33 Spanner/BoxProvisioning/ tests passed because they already opt into emulator detection.

Confirmed root cause

SpannerConnectionProvider and SpannerUnitOfWork built new SpannerConnection(configuration.ConnectionString) without opting into EmulatorDetection. Because EmulatorDetection is opt-in and absent, the client falls back to ADC and throws. The passing BoxProvisioning tests work precisely because their production SpannerConnectionHelper sets EmulatorDetection.EmulatorOrProduction.

Evidence (code-trace, verified against the emulator):

• The internal providers are exercised by the outbox/inbox test bodies (SpannerConnectionProvider.cs:22/30, SpannerUnitOfWork.cs:28/41), rebuilding from configuration.ConnectionString — so a test-object-only fix is insufficient; the fix must reach the connection string that round-trips through RelationalDatabaseConfiguration.
• SpannerConnectionStringBuilder.EmulatorDetection serialises into .ConnectionString (Google.Cloud.Spanner.Data 5.12.0), so embedding it once propagates to every derived connection.
• EmulatorDetection.EmulatorOrProduction is a no-op in real production — it only routes to the emulator when SPANNER_EMULATOR_HOST is set.

Fix

• Production parity — SpannerConnectionProvider and SpannerUnitOfWork now build their connection string via SpannerConnectionStringBuilder { EmulatorDetection = EmulatorDetection.EmulatorOrProduction }, matching the existing SpannerConnectionHelper.
• Test-side — the Gcp test connection string (Const.ConnectionString) embeds EmulatorDetection so the pre-existing Spanner outbox/inbox tests reach the emulator.
• Regression test — SpannerConnectionProviderEmulatorTests builds the production provider from a bare connection string and asserts it routes to the emulator (was red with the ADC error, now green).

Verification (emulator)

• New regression test: green.
• --filter "FullyQualifiedName~Spanner" with collection parallelisation disabled: 94 passed / 0 failed (33 BoxProvisioning kept green — no regression; all 60 ADC failures resolved).

Out of scope — tracked separately (#4224)

Under a parallel dotnet test run, ~28 Spanner Outbox/Inbox tests still fail with FailedPrecondition: Schema change operation rejected because a concurrent schema change operation ... is already in progress. That is a different root cause — the emulator serialises DDL while those test classes run in parallel (unlike BoxProvisioning, which uses a shared [Collection]). It was previously masked by the ADC failure and only surfaced once emulator detection let the tests reach the DDL stage. Filed as #4224; each test passes in isolation / when serialised.

Fixes #4162

[claude]

Code Review — PR #4225: Honour Spanner emulator detection in outbox/inbox connections

Thorough, well-diagnosed fix. The bugfix.md trace is excellent — the root-cause reasoning (EmulatorDetection is opt-in, serialises into the connection string, and must round-trip through RelationalDatabaseConfiguration into the internal providers) is convincing, and the fix mirrors the existing SpannerConnectionHelper pattern. A few observations, mostly minor.

Design / behaviour

1. Unconditional override of a user-supplied EmulatorDetection (worth a deliberate decision). Both SpannerConnectionProvider and SpannerUnitOfWork now force EmulatorDetection = EmulatorOrProduction onto whatever connection string the caller provided. If a production user had explicitly set EmulatorDetection=None (the driver default) or ProductionOnly in their connection string — e.g. to guarantee the client never routes to a SPANNER_EMULATOR_HOST that happens to be set in the environment — this silently overrides that choice. Per CLAUDE.md's "do not change defaults beyond what was requested," this is a real (if small) change to production behaviour, not just a test fix.

   • It's defensible because it matches SpannerConnectionHelper (BoxProvisioning already does this) and EmulatorOrProduction is a no-op unless the env var is set. But consider only applying it when the keyword isn't already present, so an explicit caller choice is respected:
     ```csharp
     var builder = new SpannerConnectionStringBuilder(configuration.ConnectionString);
     if (!builder.ContainsKey("EmulatorDetection"))
     builder.EmulatorDetection = EmulatorDetection.EmulatorOrProduction;
     ```
     Not a blocker given the parity argument — but the override is the one behavioural decision here that deserves to be intentional rather than incidental.

2. Null/empty connection string. Previously _connectionString = configuration.ConnectionString passed a null/empty value straight through; now it flows into new SpannerConnectionStringBuilder(...) in a field initializer. If a mis-configured caller passes null, the failure mode (and stack) changes. Low risk in practice — production always supplies a connection string — but flagging since the construction site moved earlier (field init, before GetConnection).

3. Duplication (minor / DRY). The new SpannerConnectionStringBuilder(...) { EmulatorDetection = EmulatorOrProduction } idiom now appears in four places (provider, UoW, SpannerConnectionHelper, test Const). SpannerConnectionHelper is internal to a different project so sharing isn't free, but a small helper in Paramore.Brighter.Spanner that both the provider and UoW call would keep the two production copies from drifting.

Tests

• The new SpannerConnectionProviderEmulatorTests is the right regression: it drives the production provider from a bare connection string (built inline rather than via Const, so it stays honest after Const is patched) and proves the emulator path end-to-end with SELECT 1. Good call documenting that it was RED with the ADC error before the fix.
• Like the rest of the Spanner suite it requires live emulator infra ([Trait("Category", "Spanner")]) — consistent with existing conventions, so no concern, just noting it isn't a unit-level guard.

Scope / housekeeping

• The remaining 28 parallel-DDL failures being split out to Spanner Outbox/Inbox emulator tests collide on concurrent DDL (need serialized collection) #4224 with a clear rationale (emulator serialises DDL; these classes lack a shared [Collection]) is the right call — keeps this PR to one root cause.
• .gitignore addition (docker-compose-*.local.yaml) and the bugfixes/0004-* artifacts are consistent with the existing tracked bugfixes/ convention (0001–0003). No concern.

Summary

Correct, minimal, well-tested fix that resolves #4162. The only point I'd ask the author to consciously sign off on is #1 — the production providers now unconditionally impose EmulatorOrProduction, overriding any explicit EmulatorDetection a caller set. If that's the intended parity with BoxProvisioning, ✅ ship it; the conditional variant above is a cheap way to be a touch more conservative.

[lillo42]

Should it be done in the IAmARelationalDatabaseConfiguration?

Like

new RelationalDatabaseConfiguration(new SpannerConnectionStringBuilder("MyConnection")
        {
            EmulatorDetection = EmulatorDetection.EmulatorOrProduction
        }.ConnectionString)