Known limitations / risk register

Soundverse 2.0 is a fast-moving greenfield rebuild, and it has debt. None of it is a surprise — the items below are known, and the full analysis (46 findings confirmed adversarially against the code) lives in the architecture review at backend/core/docs/INFRA-REVIEW.md. None of this blocks local development or normal feature work. Think of each item as an edge to respect when you touch the relevant area, not a landmine in your path. Where live state matters, the item carries a status badge.

One vocabulary note

The full review was written before the auth migration, so it says “Zitadel” throughout. Auth is now self-hosted Logto in both core-identity and the frontend — read every “Zitadel” in the audit as “Logto”. See Identity & auth.

The three P0 blockers exploitable as deployed

These are the items to fix before any further external exposure. All three are still live in the current tree (verified against staging).

1 · core-mcp is internet-facing and trusts a spoofable header

core-mcp deploys with enable_ingress: true and is_external: true (target_port: 8080), and derives identity from a request header via scope.HeaderResolver — it reads X-Soundverse-User-Id verbatim and always returns a nil error. There is no validated token behind it, and no INTERNAL_RPC_SECRET gate on /mcp. Any host can POST /mcp with a forged user id (X-Soundverse-User-Id: <target-user>) to drain a victim’s token balance, queue generations into their workspaces, and bind outputs to their chat messages. The fix is to set is_external: false, gate /mcp behind INTERNAL_RPC_SECRET, and derive identity from a validated token. Do not treat core-mcp as a hardened public entry point — its front door is changing.

2 · The billing pipeline is reimplemented in two languages

The reserve → price → rate-limit → settle pipeline exists in both core-gateway-consumer (Python) and core-mcp (Go), with byte-identical idempotency suffixes — :settle-extra, :settle-refund, :refund-all — and copied pricing math. A change to a suffix string or the cost formula in one language will not fail to compile in the other; it just quietly diverges, and once the suffixes disagree, settlements stop deduping across the two reconcilers and double-charging becomes possible. The strategic fix is a single billing/orchestration owner. Until then, see the trap callout below. Background: the token ledger & money path and the agent + MCP path.

3 · core-storage mints SAS URLs with no ownership check

core-storage serves its gRPC surface over add_insecure_port (no inbound auth interceptor), and CreateDownloadLink takes only a blob_hash, resolves the blob, and signs a SAS URL — with no user_id and no caller-owns-the-file check. The only ownership gate lives in the gateway. Any internal caller (a worker, a new service) that holds a blob_hash can mint a working signed URL to another tenant’s private asset. The fix is to pass an authenticated user_id into CreateDownloadLink, verify a non-deleted owned file references the hash, and add an inbound auth interceptor — defense in depth, not one layer. See Storage & media plane.

The rough-edge inventory (P1 / P2 / by-design)

Everything below is tracked and bounded — mostly “coordinate by hand” or “throughput-capped, not lost.” Full severity and evidence for each is in backend/core/docs/INFRA-REVIEW.md (sections 4–6).

Area	Current state	What to watch for	Status
Auth env drift (Zitadel → Logto)	core-identity and the live frontend are Logto-wired, but root .env.example and the compose soundverse-saas-2.0 service still only carry AUTH_ZITADEL_* slots (plus a NEXT_PUBLIC_ZITADEL_GOOGLE_ORG build arg). There are no AUTH_LOGTO_* / LOGTO_M2M_* slots yet.	make up-frontend hands the Logto frontend dead vars, so browser sign-in won’t authenticate out of the box. Set AUTH_LOGTO_* (and the LOGTO_M2M_* creds identity needs) by hand — see Configure Logto.	Config drift
No DB migration tooling	schema.sql is hand-applied reference DDL. There is no Atlas / goose / Alembic runner — nothing versions, applies, or diffs it.	Keep schema.sql, the db_column proto annotations, and the live DB in lockstep by hand, and coordinate any DDL change with the proto release that needs it.	P1
Missing task fencing token	ClaimNextTask re-claims a task whose lease expired, but CompleteTask / FailTask carry no owner guard — the lease is time-only, with no claimed_by liveness.	A stalled-but-live worker can have its task stolen and both run → duplicate provider spend and uploads. Token billing stays single-charged (stable settle keys). See Task queue.	P1
Prod proto cascade gap	The prod release fires a proto_updated_prod dispatch, but consumers listen for soundverse_updated / proto_updated, and the Go services are bumped by hand.	A prod contract change does not auto-propagate. Coordinate prod proto changes manually — see the proto → deploy cascade.	P1
Schema-skew not caught in CI	buf breaking is intentionally disabled for the startup phase. Python/web consumers pin @staging; the Go services pin a frozen pseudo-version.	A wire-compatible-but-semantic change (reused field number, unit change) is only caught at compile/runtime, not in CI.	By design
Redis is single-replica	One Redis serves as cache, task queue, and event bus at once — a single point of failure. A configured-but-down Redis fails requests closed (errors before reserve/queue), not open.	A Redis blip stops generation and live streaming together. Fail-safe (no double-charge), but not highly available.	P2
Fixed worker autoscaling	Workers deploy with hardcoded --min-replicas 1 --max-replicas 10 and no KEDA queue-depth rule. Workers have no HTTP ingress, so ACA’s default HTTP/concurrency scaler never fires.	A burst queues behind one replica per tool — throughput-capped (bounded by per-worker concurrency), not lost.	P2
gRPC services lack a real readiness probe	The deploy template emits only an httpGet probe, which can’t probe a pure-gRPC port, so application-level unreadiness (process up, downstream channel dead) goes undetected.	Rolling deploys can briefly sever in-flight streams. Recoverable via the reconciler / stream auto-reconnect — churn, not data loss.	P2

Two traps worth their own callout

The duplicated pipeline is the one that bites silently

Because the suffix strings and pricing math are copied between core-mcp/internal/billing/billing.go and core-gateway-consumer/app/enforcement/billing.py, a change in one language won’t fail to compile in the other — it just diverges. If you edit either, grep for the same strings in the sibling repo and change both in the same PR.

'Configured-but-down Redis fails closed' — not a billing hole

An earlier analysis claimed a Redis outage silently disables rate-limiting while billing keeps charging. That was refuted: when Redis is configured but unreachable, the pipeline errors out before it reserves tokens or queues a task. The fail-open Allowed: true branch only fires when Redis is unconfigured. The real residual risk is availability (single-replica Redis), not a billing safety hole.

The honest bottom line

Local dev and normal feature work are unaffected by everything above. The three P0s are deployment/exposure risks, not local blockers; the rest are “coordinate by hand” edges. When you do touch one of these areas, the full review at backend/core/docs/INFRA-REVIEW.md (sections 4–6) has the severity, evidence, and recommended fix for each — plus the P1/P2/P0 priority ordering and the open architectural questions the team still has to answer (is core-mcp a public peer or an internal detail? should nested agent calls bill once or twice? AKS or ACA for core-database?).

Related

core-mcpThe open-auth P0, the schema cache, and replica pinning.

core-storageWhere CreateDownloadLink and SAS minting live.

Token ledger & money pathThe billing pipeline the two gateways duplicate.

The proto → deploy cascadeWhy the prod cascade needs manual coordination.

Troubleshooting FAQOne-line fixes for the failures you'll actually hit.

Repository catalogAll ~20 submodules that make up the fleet.