fix(firestore-send-email): keep SMTP_PASSWORD available so SendGrid works with AUTH_TYPE=OAuth2

[cabljac]

SendGrid sends fail in the kit when AUTH_TYPE=OAuth2. configFromEnv gates secrets on the auth type and forces smtpPassword to undefined under OAuth2, but transportLayer selects the SendGrid transport purely on the SMTP URI host (smtp.sendgrid.net) and passes smtpPassword as the SendGrid API key. The transport therefore got apiKey: undefined, sgMail.setApiKey was never called, and every send failed. The legacy extension reads SMTP_PASSWORD unconditionally (firestore-send-email/functions/src/config.ts and index.ts:86-90 on master), so SendGrid + OAuth2 worked there.

The fix passes the SMTP password secret through for every auth type, and secretParamsForAuthType now keeps SMTP_PASSWORD bound under OAuth2 so a future gated deploy binding cannot reintroduce the bug. New tests pin configFromEnv keeping the secret under OAuth2 and transportLayer handing the key to setApiKey; the changelog gets an entry. Rebased onto kits after #3057 merged, folding the new tests into the ported suites. Suite: 123 tests pass, tsc --noEmit clean. An adversarial review mutation-tested both halves of the fix (reverting config.ts fails the config tests, reverting the transport apiKey fails the transportLayer test) and found no regression in any consumer of smtpPassword; the obfuscated-config log path still redacts it. Caveat: no live SendGrid send was verified; the behavior is pinned at unit level against a mocked @sendgrid/mail.

Fixes #3009

[gemini-code-assist]

Code Review

This pull request updates the firestore-send-email kit to keep the SMTP_PASSWORD secret bound under OAuth2 authentication, ensuring that the SendGrid transport layer receives its API key. It also adds a new test suite for the transport layer and updates existing configuration tests. The reviewer noted that unconditionally binding SMTP_PASSWORD under OAuth2 would cause a usability regression for non-SendGrid OAuth2 users (e.g., Gmail OAuth2) by forcing them to provide a dummy password. To address this, the reviewer suggested conditionally binding and resolving SMTP_PASSWORD only when the SMTP connection URI points to SendGrid, moving the test cleanup hook to the top level, and adding corresponding test cases for both scenarios.

[IzaakGough]

The fix looks right. transportLayer checks isSendGrid before setSmtpCredentials, so the SendGrid branch is reachable under AUTH_TYPE=OAuth2 and now gets a real API key, and un-gating smtpPassword is safe for the OAuth2 non-SendGrid path because setSmtpCredentials returns setupOAuth2 before touching it. logs.ts still redacts it, and nothing else reads it. Verified locally at this head: 123 tests pass, typecheck and prettier clean, and restoring the old OAuth2 gate makes the new config test fail, so it does pin the behaviour.

One thing outside the diff that I think is worth including here: kits/firestore-send-email/README.md around line 156 still tells OAuth2 installs to create SMTP_PASSWORD with a placeholder value. Someone on SendGrid who follows that ends up at sgMail.setApiKey("<placeholder>") and every send fails with a 401, so the setup path the CHANGELOG entry describes as fixed still breaks. A short carve-out saying the real API key goes in SMTP_PASSWORD when the connection URI is smtp.sendgrid.net, whatever AUTH_TYPE is set to, would cover it.

The two inline notes are both about test durability rather than current behaviour, so neither needs to block.

[IzaakGough]

Closed out the testing on a live SendGrid key, running the kit in the functions emulator with AUTH_TYPE=OAuth2 and the SendGrid connection URI.

The config change does what it says. smtpPassword now reaches the transport, where before it was absent from the resolved config entirely. With a real key the request authenticates and SendGrid answers at the account level, so setApiKey and send both complete the round trip. That last part only became reachable with 2c2a325, since before it the transport threw on setApiKey regardless of auth type.

What is not proven: the send stopped at Maximum credits exceeded, so delivery.state: SUCCESS and the sendgridQueueId parsing never ran. That path is untouched here and covered by the existing unit tests, so it did not seem worth chasing a credited account. The control is useful though, a deliberately fake key on the same rig returns The provided authorization grant is invalid, expired, or revoked, so the credits response is SendGrid resolving the key to an account rather than rejecting it.

All of this was the emulator rather than a real deploy, so deploy-time secret binding onto the service is still untested.

[IzaakGough]

Took this to a live deploy on a test project to cover the one thing the emulator cannot reach, deploy-time secret binding.

The deployed service binds all four secrets as env vars, SMTP_PASSWORD included, under AUTH_TYPE=OAuth2. A document written to the real mail collection was picked up, the function read the key out of Secret Manager, built the SendGrid transport and authenticated, landing on the same Maximum credits exceeded as the emulator run. The transport constructing at all is 2c2a325 working in a deployed build, since the previous one died at setApiKey before any network call.

One thing found along the way, separate from this PR's subject. Secret params resolve to two different resources depending on which layer of the deploy is asking. applyPrefix rewrites each endpoint's secret env vars to kit-<instance id>-<PARAM>, but it does not set resourceId on the params, so the params layer falls through to the bare name. Both halves are observable:

• The params layer reaches for the bare name. An instance with no secrets of its own bound onto an unrelated project level SMTP_PASSWORD that happened to exist, and a missing one reports In non-interactive mode but have no value for the secret CLIENT_ID: CLIENT_ID, followed by Set this secret before deploying: firebase functions:secrets:set CLIENT_ID.
• Endpoint validation then asks for the prefixed name: Secret [projects/.../secrets/kit-default-SMTP_PASSWORD] not found or has no versions.

So following the CLI's own suggestion creates a secret the deploy then ignores, and functions:secrets:set cannot create the prefixed name either, since it uppercases the argument and KIT_ is a reserved prefix. Creation uses that same bare resourceId, so the interactive prompt should land in the same place, though I did not drive the prompt itself.

What does work today is FIREBASE_SECRET_REF_<PARAM>=projects/<p>/secrets/<name>/versions/latest in the instance's .env. It overrides both layers, takes any resource name, and needs no prompt, so it is also the only CI safe route. That one I confirmed with a dry run rather than a completed deploy. Creating kit-<instance>-<PARAM> by hand with gcloud works too, and is what got the deploy above through.

For anyone coming from an extension none of this should be manual. firebase ext:export --mode functions writes those same FIREBASE_SECRET_REF_ entries pointing at the live ext-<instance>-<PARAM> resources, with a secret ejection prompt alongside. That sits behind the private extMigrationFeatures experiment and ext:migrate is currently a stub, so it is not usable yet. That paragraph is from reading firebase-tools 15.29.0 rather than running it.

This looks like a firebase-tools issue rather than anything to change in this PR, and the kit README wording is downstream of whatever it settles on.