fix(rr): decouple agentSandbox postgres from externalSecret (use postgres.urlSecretName); require encryption key

[JatinNanda]

what

setting rr.agentSandbox.externalSecret.name (intended just for the JWT keypair) silently overloaded two unrelated things, breaking enablement on a deployment that only wanted to reuse its existing backend postgres:

• postgres hijack — postgresUrlEnv routed AGENT_SANDBOX_POSTGRES_URL to the external secret's postgres-url key. missing key → getaddrinfo ENOTFOUND at runtime. the inherit-the-backend path was unreachable whenever externalSecret.name was set, and validateSecrets counted it as an explicit pg source so nothing failed at template time.
• encryption key was treated as optional — but it isn't. the proxy derives the sandbox-iframe asset-token HMAC key from AGENT_SANDBOX_ENCRYPTION_KEY (agent_executor/proxy/src/config.ts getAssetTokenHmacSecret) and throws the first time it serves a sandbox if it's missing. the pod comes up green and then fails at first use.

separately, the snapshot blob-storage env never reached the workflow worker, even though the agent/snapshot temporal activities run there.

changes

• externalSecret.name now covers only the JWT/encryption keys — it never sources postgres. to read a DSN from that same secret, point postgres.urlSecretName at it (Option 3; urlSecretKey defaults to postgres-url). otherwise postgres inherits config.postgresql — an existing deployment needs no DB config.
• require the agent sandbox encryption key in validateSecrets (mirrors the JWT-key checks) — fail loudly at render instead of shipping a pod that breaks at first sandbox use; both fail hints point at postgres.urlSecretName
• render gitServer.commonEnv (RR_DEFAULT_*) onto the workflow worker when rr.gitServer.enabled. the agentExecutor/snapshotRetention temporal activities run on WORKFLOW_TEMPORAL_WORKER and read snapshot blob storage (getBlobStoreForSnapshots, RR_SNAPSHOTS_* → RR_DEFAULT_* fallback), but commonEnv was only injected onto the backend + standalone git-server pod — so the worker had no creds and snapshot access failed there.
• values.yaml (both copies): drop postgres-url from the externalSecret.name key list, mark encryptionKey required (64 hex, openssl rand -hex 32)
• bump chart 6.11.1 → 6.11.2; update ci/ fixtures to supply the now-required encryption key

incorporates #332

pulled in @ryanartecona's passwordSecretName support so the two don't collide. in the final shape it lives in the postgres.urlSecretName branch: the blueprints case (DSN from the agent-sandbox secret, password from the auto-rotated main secret) is postgres.urlSecretName: agent-sandbox-env + postgres.passwordSecretName: retool-config.

note: an earlier revision used a postgres.fromExternalSecret boolean — redundant with postgres.urlSecretName, since removed in favor of it.

testing

helm template verified: urlSecretName routes to the secret's postgres-url (+ PGPASSWORD when passwordSecretName set); JWT-only externalSecret inherits the backend DSN; render fails with a clear error when no encryption-key source is set; the workflow worker now renders RR_DEFAULT_* when gitServer.enabled + blobStorage is set. all ci/ fixtures render; helm lint clean.

note: same-origin-on-HTTPS (a separate reported issue) is a backend gap, not chart-fixable, and is out of scope here.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR decouples agentSandbox.externalSecret.name from Postgres sourcing (it now covers only JWT/encryption keys), promotes encryptionKey from optional to required in validateSecrets, and adds gitServer.commonEnv (blob-storage vars) to the workflow worker so snapshot activities can reach blob storage.

• Postgres decoupling: $explicitPg no longer includes $ext; the old externalSecret.name → postgres-url branch in postgresUrlEnv is removed and replaced by the explicit postgres.urlSecretName path (Option 3), which now also supports a separate passwordSecretName for auto-rotated passwords.
• Encryption key enforcement: a new validateSecrets guard fails at render time if neither encryptionKey nor externalSecret.name is set, preventing the silent pod-starts-but-throws-at-first-sandbox-use failure.
• Worker blob-storage env: retool.gitServer.commonEnv is now injected into all worker deployments when rr.gitServer.enabled, surfacing RR_DEFAULT_* so agentExecutor/snapshotRetention temporal activities can resolve blob storage on the worker node.

Confidence Score: 5/5

Safe to merge — the three independent fixes (postgres decoupling, encryption key enforcement, worker blob-storage env) each address a clear breakage with no new footguns introduced.

All three changes are narrowly scoped to the agentSandbox / gitServer path, the validation logic is sound (fail messages are accurate, the $explicitPg simplification is correct), the CI fixtures now supply the required encryption key, and the postgresUrlEnv template correctly handles the new urlSecretName + passwordSecretName combination. No pre-existing behaviour outside the changed paths is affected.

No files require special attention.

Important Files Changed

Filename	Overview
charts/retool/templates/_helpers.tpl	Core fix: removes externalSecret.name from $explicitPg check, adds encryptionKey require-guard, removes the postgres-url branch from postgresUrlEnv, adds passwordSecretName support in the urlSecretName path — logic is consistent and validation messages are accurate.
charts/retool/templates/_workers.tpl	Adds retool.gitServer.commonEnv (blob-storage vars) to the worker deployment template when gitServer.enabled; applied to all worker types — harmless for non-workflow workers and consistent with how backendEnvVars is already injected.
charts/retool/values.yaml	Removes Option 4 (externalSecret postgres-url), marks encryptionKey as REQUIRED, adds clarifying comments for urlSecretName/passwordSecretName; accurate and consistent with template changes.
charts/retool/ci/test-agent-sandbox-enabled-option.yaml	Updates the CI fixture from the old Option 4 path to Option 3 (urlSecretName pointing at the same secret as externalSecret.name); correctly exercises the new behavior.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[agentSandbox.enabled] --> V[validateSecrets]
    V --> PG{postgres explicit?}
    PG -- "url / host / urlSecretName set" --> PG_OK[explicit path OK]
    PG -- none set --> INHERIT{config.postgresql has host?}
    INHERIT -- yes --> PASS_OK[inherit backend PG]
    INHERIT -- no --> FAIL1[fail: set postgres.url / .host / .urlSecretName]
    V --> ENC{encryptionKey or externalSecret.name?}
    ENC -- yes --> ENC_OK[encryption key present]
    ENC -- no --> FAIL2[fail: set encryptionKey or externalSecret.name]
    V --> JWT{jwtPublicKey or externalSecret.name?}
    JWT -- yes --> JWT_OK[JWT keys present]
    JWT -- no --> FAIL3[fail: set jwtPublicKey]
    PG_OK --> ENV[postgresUrlEnv]
    PASS_OK --> ENV
    ENV --> OPT1[postgres.url - value literal]
    ENV --> OPT2[postgres.host - assembled URL + PGPASSWORD]
    ENV --> OPT3[postgres.urlSecretName - secretKeyRef + optional PGPASSWORD]
    ENV --> OPT4[default - inherit backend config.postgresql]
    GS{rr.gitServer.enabled?} -- yes --> BLOBENV[gitServer.commonEnv RR_DEFAULT_* blob-storage vars]
    BLOBENV --> W[all worker pods]
    GS -- no --> W

Loading

_{Reviews (4): Last reviewed commit: "chore(rr): bump chart version to 6.11.3 ..." | Re-trigger Greptile}

[ryanartecona]

uhhh what do you think about instead of rr.agentSandbox.postgres.fromExternalSecret: true, we just mirror the pattern we have for other stuff already and introduce rr.agentSandbox.postgres.urlSecret{Name,Key}? that is IMO more flexible & straightforward with the slight tradeoff of being slightly more verbose.