I tried to send this to support, but we’re at the free tier. I’ll paste it below, but the tl;dr is that we have one data connector that no longer auths properly after an employee left. I’ve transferred full ownership to me, and have tried editing the connector, duplicating it, and recreating it. Each time, I get a 403 or 503 in the console when I select “Authenticate”, with or without SSL enabled (I uploaded our PEM), over many days.
Has anyone seen this before, and resolved it?
We are unable to authenticate any PostgreSQL data source connection in this report — not a brand-new connection, not a duplicate of an existing working connection, and not a credential update on an existing data source. Every attempt to submit credentials (clicking Authenticate on a new/duplicated source, or Reconnect on an existing one) fails with the same client-side error, tied to a failing internal call to POST ``https://datastudio.google.com/getAccountTree. We’ve reproduced this consistently over several days, across multiple browsers, with and without a VPN, and across three different action types (new connection, duplicate, and reconnect). We’ve independently confirmed the underlying database and credentials are valid and reachable, so the failure appears to be isolated to this specific Looker Studio API call, not to our database or network configuration.
Business impact
Five charts on a live, in-use analytics dashboard have been unable to display data for an extended period. We’ve identified the exact configuration change needed to fix them (enabling SSL on the connector, described below) but cannot apply it because every save attempt is blocked by this error.
Steps to reproduce
- Open the report above in edit mode.
- Go to Resource → Manage added data sources.
- Click Edit on any PostgreSQL-connector data source (this reproduces on an existing reusable source, an existing embedded duplicate, and a freshly created connection — all three).
- Enter host / port / database / username / password, and toggle Enable SSL as needed.
- Click Authenticate (new/duplicate source) or Reconnect (existing source).
- Observe: the browser console shows a failing
POST .../getAccountTreecall (we’ve seen both403 Forbiddenand503 Service Unavailableon different attempts), immediately followed by:
TypeError: Cannot read properties of undefined (reading 'errorStatus')
and an unhandled promise rejection. The credential/config change does not save — reopening the same data source afterward shows it reverted to its prior (unauthenticated) state.
Representative console output (403 variant)
POST https://datastudio.google.com/getAccountTree?appVersion=20260802_0000 403 (Forbidden)
...
m=pm_base:2434 TypeError: Cannot read properties of undefined (reading 'errorStatus')
at lg_OSe (...)
at lg_NSe.UHb (...)
at _.lg_ZW (...)
...
'Possibly unhandled rejection: {}'
Representative console output (503 variant)
POST https://datastudio.google.com/getAccountTree?appVersion=20260802_0000 503 (Service Unavailable)
...
m=pm_base:2434 TypeError: Cannot read properties of undefined (reading 'errorStatus')
...
'Possibly unhandled rejection: {}'
Both variants produce the identical downstream TypeError and unhandled rejection — only the initial HTTP status code on getAccountTree changes between attempts.
What we’ve already ruled out
- Browser/session state: Reproduced in a normal browser window and in a fresh incognito window with a clean login.
- VPN/network path: We run Tailscale; reproduced identically with it enabled and disabled.
- Scope of the action: Reproduced when (a) updating credentials on an existing embedded data source, (b) duplicating a data source (including duplicating one that is currently authenticated and working) and attempting to authenticate the copy, and (c) creating an entirely new PostgreSQL connection from scratch. All three paths fail the same way.
- Database/network layer: We connected directly to the target database from outside Looker Studio (via
psql, with SSL) using the same credentials we’re trying to enter in the connector dialog, and the connection succeeds cleanly. This confirms the database, its security group rules, and the credentials themselves are all valid — the failure is specific to Looker Studio’s connector-authentication flow. - Comparison against a working connector: A separate, already-authenticated PostgreSQL data source in the same report connects to the exact same database host successfully and is unaffected — its “Working” status is real, not stale. It only differs from the broken source in its stored username and SSL setting, both of which we’ve now confirmed via direct database testing to be the correct fix. We simply cannot get that fix to save due to this error.
Relevant timing note
This report’s data sources previously all had a different owner — a Workspace user who has since been deleted from our domain, with ownership intended to transfer to the reporting admin. Most other data sources in this report continued working normally after that change, but we want to flag the timing in case it’s relevant to whatever getAccountTree is trying to resolve for this account (e.g., an API grant, service permission, or cached account/asset mapping that didn’t fully transfer).
What we’re asking for
We’d like help getting past this specific failure so we can either:
- Successfully authenticate a duplicate (or brand-new) PostgreSQL data source using our verified-working credentials, or
- Successfully update the credentials/SSL setting on the existing (currently broken) data source.
Either path resolves the underlying issue on our end — we just need one working submission through the connector-authentication flow. We’d also appreciate knowing whether this is a known/tracked issue, something specific to our account or domain, or a broader service problem, so we know what to expect going forward.