fix(data-connections): align provider values to the backend vocabulary

[alukach]

Problem

Creating a GCP data connection persisted details.provider: "gcp", but the data proxy (data.source.coop) reads details.provider directly and only accepts "gcs"/"gs" for Google — never "gcp". The same latent mismatch existed for Azure ("az" vs the accepted "azure"). The provider→storage_type map already emitted the right values, so mirrors were fine — only the stored provider string was wrong.

Change — rename DataProvider values to what the backend accepts

enum DataProvider { S3 = "s3", Azure = "azure" /* was "az" */, GCS = "gcs" /* was GCP="gcp" */ }

• Member GCP→GCS, schema/type Gcp*→Gcs*. Auth type stays gcp_workload_identity (WIF is a GCP-platform feature, not storage). Provider labels spelled out in the form.
• Maps kept — the now-redundant provider→storage_type translation is left in place here and removed in the stacked follow-up (refactor(mirrors): drop denormalized ProductMirror.storage_type #456).

Migration (legacy az/gcp rows)

A one-time script — scripts/migrate-provider-values.ts — converts persisted details.provider values ("az"→"azure", "gcp"→"gcs"), matching the repo's existing migration convention (positional table arg, DynamoDB scan + guarded UpdateCommand, progress logging). Dry-run by default; --apply to write. Re-runnable (canonical rows are skipped). Run it (dry-run, then --apply) at/before deploy:

npx tsx scripts/migrate-provider-values.ts sc-prod-data-connections          # preview
npx tsx scripts/migrate-provider-values.ts sc-prod-data-connections --apply   # write

(Earlier revisions used a runtime read-shim; replaced with this script so the DB read path carries no legacy-value handling.)

Backend compatibility (verified against data.source.coop)

S3 unchanged. Azure accepts both "az" and "azure" → compatible during rollout. GCS: old "gcp" never worked (hit the error arm); "gcs" is accepted. Pairs with data.source.coop#191 (enables the GCS backend).

Verification

tsc clean · jest affected suites green · lint clean · fixture provider fixed (az→azure) so module-load parsing passes.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
source-cooperative	Ready	Preview, Comment	Jul 22, 2026 10:29pm

[claude]

Claude finished @alukach's task in 1m 51s —— View job

---

Reviewing PR #455

• Gather context and fetch diff
• Analyze changed files for correctness/security/best-practice issues
• Post final review

---

✅ No blocking issues — safe to merge.

The rename is applied consistently: enum member (GCP→GCS), schema/type names, form labels, badge map, auth-type map, and all associated tests. storage_type in src/types/product.ts:12 already used "azure"/"gcs", so the two vocabularies now line up with no residual translation needed. No leftover references to the old "gcp"/"az" literals or GcpDataConnection naming remain outside the migration script/docs (verified via repo-wide grep).

One thing worth double-checking operationally rather than a code bug:

• src/lib/clients/database/data-connections.ts (commit b42b9bd) removed the normalizeConnection read-time shim in favor of the standalone scripts/migrate-provider-values.ts. fetchById/listAll now return DynamoDB rows as-is with no Zod validation or aliasing (return (result.Items?.[0] as DataConnection) ?? null;). Any row still holding a legacy "az"/"gcp" provider value will silently fail the Record<DataProvider, ...> lookups that assume canonical keys — e.g.:

  • src/lib/actions/product-mirrors.ts:107-117 — storageTypeByProvider[connection.details.provider] returns undefined for "az"/"gcp", producing a mirror with an undefined storage_type.
  • src/lib/actions/products.ts:22-29 — same pattern for STORAGE_TYPE_BY_PROVIDER.
  • src/components/features/data-connections/DataConnectionForm.tsx:52-54 — authTypesByProvider lookup misses, breaking the auth-type selector for an existing legacy connection loaded into the edit form.

  Since the backend currently still accepts "az" for Azure (per the PR description), an existing, working Azure connection would only break if this code deploys before the migration script is run (or the script fails/is skipped) — there's no runtime fallback left to catch that ordering mistake. This is clearly intentional (documented in the script header and the DataProvider doc comment), so it's not a defect in the diff itself — just flagging that the safety net that used to exist unconditionally now depends entirely on the migration being run first. Worth confirming the deploy runbook/CI enforces that ordering, or adding a smoke check post-deploy.

Everything else — the migration script's dry-run default, ConditionExpression guard against concurrent writes, and re-run safety — looks correct.

[alukach]

Fixed in de9b172 — fixtures/data-connections.json azure connection provider az→azure. Good catch; utils.mock.ts parses this fixture at module load so it took down every importing suite. Verified authz.test.ts (45) and the full fixture-consuming suites pass. Propagated the same fix into the stacked #456.

The remaining DropdownSection.integration.test.tsx failure is pre-existing on main and unrelated to this PR (doesn't touch that component).

[alukach]

Replaced the runtime normalizeConnection read-shim with a one-time migration script (scripts/migrate-provider-values.ts, dry-run by default, --apply to write) per request — the DB read path no longer carries legacy-value handling. Propagated into the stacked #456.