docs: fix duplicate-word typos in troubleshooting guides (#45297)

Fixes two small duplicate-word typos in troubleshooting guides:

-
`apps/docs/content/troubleshooting/using-google-smtp-with-supabase-custom-smtp-ZZzU4Y.mdx`:
"easy to to figure out" → "easy to figure out"
-
`apps/docs/content/troubleshooting/why-is-my-service-role-key-client-getting-rls-errors-or-not-returning-data-7_1K9z.mdx`:
"for for service role" → "for service role"

Pure docs typo fix — no functional changes.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

## Documentation
* Corrected grammatical errors in troubleshooting guides for Google
Workspace SMTP configuration and service-role key errors.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This commit is contained in:
Apoorva Verma
2026-04-28 18:46:00 +05:30
committed by GitHub
parent 8cddca4ad5
commit 95760d14d4
2 changed files with 2 additions and 2 deletions
@@ -10,7 +10,7 @@ database_id = "4d5390a0-445d-4e0a-ae7e-9b713b7cc4f6"
Hey everyone, i've been hearing feedback about how challenging it can be to get google SMTP working properly with Supabase. I've tried setting this up with a trial google workspace account and this is what i've discovered.
1. The sender email and SMTP username has to be your google workspace admin email.
2. The SMTP password used has to be an app password. Google workspace doesn't make it easy to to figure out how to create this. You need to **enable 2FA** on your workspace account first (not inside the admin console but in https://myaccount.google.com/)
2. The SMTP password used has to be an app password. Google workspace doesn't make it easy to figure out how to create this. You need to **enable 2FA** on your workspace account first (not inside the admin console but in https://myaccount.google.com/)
3. If you want to use `smtp-relay.gmail.com` only port 465 works. If you want to use `smtp.gmail.com`, you can use port 465 or 587.
The following screenshots show what those steps look like:
@@ -22,6 +22,6 @@ Three common cases of the `createClient` `apikey` being replaced by a user sessi
2. Edge functions or other server code setting the `Authorization` header in `createClient` options directly to a user token/JWT. When you set the `Authorization` header directly that overrides the default action of using the `apikey` for the `Authorization` header.
3. Server client initialized with service role using `signUp` to create a user or other auth functions. Many auth functions will return a user session to the client making the call. When that happens the `apikey` will be replaced by the user token/JWT in the `Authorization` header. If you are wanting to create a user in a service role client use `admin.createUser()` instead. Otherwise use a separate Supabase client for for service role from other actions.
3. Server client initialized with service role using `signUp` to create a user or other auth functions. Many auth functions will return a user session to the client making the call. When that happens the `apikey` will be replaced by the user token/JWT in the `Authorization` header. If you are wanting to create a user in a service role client use `admin.createUser()` instead. Otherwise use a separate Supabase client for service role from other actions.
Also note that adding `service_role` in RLS policies does nothing. Service role will never run the policies to begin with.