Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret

[ryanartecona]

In blueprints, we want the agentSandbox secrets to come from different places: jwt-public-key, jwt-private-key, and postgres-url from an agent-sandbox secret, but specifically the postgres password from the main retool secret, as that is the only one that gets auto rotated by e.g. RDS.

This allows agentSandbox.externalSecret to also be used with agentSandbox.postgres.passwordSecretName when both are present.

[greptile-apps]

Greptile Summary

This PR extends retool.agentSandbox.postgresUrlEnv so that when externalSecret.name supplies the postgres-url, a separately configured postgres.passwordSecretName (e.g. the main Retool secret auto-rotated by RDS) is also injected as PGPASSWORD. This enables the blueprint use-case where JWT keys and the postgres URL come from one external secret while the password comes from another.

• Adds a conditional PGPASSWORD secretKeyRef block inside the $ext branch of retool.agentSandbox.postgresUrlEnv, mirroring the existing pattern already present in the $pg.host branch.
• Bumps the chart to 6.11.1 and updates comments in both values.yaml copies to document the new combination.

Confidence Score: 4/5

The externalSecret path change is correct; the urlSecretName branch is left without equivalent passwordSecretName support, which could silently drop the password for users who pair those two options.

The new PGPASSWORD block in the externalSecret branch is logically correct and mirrors the existing host-path pattern. The concern is that the parallel urlSecretName branch still has no passwordSecretName support — a user storing a passwordless DSN via urlSecretName and setting passwordSecretName will silently get no PGPASSWORD at runtime.

charts/retool/templates/_helpers.tpl — specifically the urlSecretName branch around line 738

Important Files Changed

Filename	Overview
charts/retool/Chart.yaml	Patch version bump from 6.11.0 to 6.11.1 to reflect the bugfix change.
charts/retool/templates/_helpers.tpl	Adds PGPASSWORD env var support to the externalSecret branch of retool.agentSandbox.postgresUrlEnv; the urlSecretName branch gets no equivalent treatment, creating an asymmetry.
charts/retool/values.yaml	Comment-only update documenting that the postgres-url from externalSecret can omit the embedded password and use passwordSecretName instead.
values.yaml	Mirrors the same comment-only update as charts/retool/values.yaml.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[retool.agentSandbox.postgresUrlEnv] --> B{pg.url set?}
    B -- Yes --> C[AGENT_SANDBOX_POSTGRES_URL = plaintext url]
    B -- No --> D{pg.host set?}
    D -- Yes --> E{passwordSecretName?}
    E -- Yes --> F[PGPASSWORD from secret]
    E -- No --> G{pg.password?}
    G -- Yes --> H[PGPASSWORD plaintext]
    F --> I[AGENT_SANDBOX_POSTGRES_URL assembled from host/user/db]
    H --> I
    G -- No --> I
    D -- No --> J{pg.urlSecretName set?}
    J -- Yes --> K[AGENT_SANDBOX_POSTGRES_URL from secret - NO PGPASSWORD support]
    J -- No --> L{externalSecret.name set?}
    L -- Yes --> M[AGENT_SANDBOX_POSTGRES_URL from external secret]
    M --> N{passwordSecretName? NEW}
    N -- Yes --> O[PGPASSWORD from passwordSecretName secret]
    N -- No --> P[no PGPASSWORD]
    L -- No --> Q[Inherit backend postgres - PGPASSWORD from config.postgresql secret]

Loading

Comments Outside Diff (2)

1. charts/retool/templates/_helpers.tpl, line 701-702 (link)

   The docblock says "plus a PGPASSWORD entry when assembling from fields" but after this PR, PGPASSWORD can also be emitted in the externalSecret path. The phrase "when assembling from fields" now understates the scope — callers reading this comment before the externalSecret branch won't expect PGPASSWORD to appear there.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

2. charts/retool/templates/_helpers.tpl, line 738-743 (link)

   urlSecretName branch silently ignores passwordSecretName

   The externalSecret branch (just below) now respects passwordSecretName, but the urlSecretName branch does not. A user who stores a passwordless DSN in a Kubernetes secret via urlSecretName and sets passwordSecretName to provide the password separately will get no PGPASSWORD env var and a silent connection failure at runtime. The urlSecretName path could apply the same {{- if $pg.passwordSecretName }} block that was just added to the externalSecret path.

_{Reviews (1): Last reviewed commit: "bump patch" | Re-trigger Greptile}