I investigated the issue with the help of AI. Here is what it says about it! 
Adding more data to this thread — same symptom, with extra debugging info that I think narrows it down to a backend regression rather than a client-side issue.
Same surface error on copyDatasourceAndRedirect/{datasource-id} (and presumably copyReport): a new tab opens, fails with ERR_INVALID_RESPONSE, and the Network panel shows the POST as (blocked:origin).
Underlying server response. I intercepted the form submission and replayed the POST in the current tab via fetch() to get past the chrome-error rendering. The actual response is:
HTTP/1.1 400 Bad Request
Content-Type: application/json
)]}'
{"errorStatus":{"code":3}}
code: 3 is INVALID_ARGUMENT in Google’s standard error mapping. The ERR_INVALID_RESPONSE users see is just Chrome failing to render that JSON body as a page (the form has target="_blank", so the new tab tries to load the response as a document, can’t, and falls back to a chrome-error://chromewebdata/ page).
Same 400 / code 3 reproduced with all of the following variations, so these can be ruled out as causes:
-
Native form POST with target="_blank" (current production path)
-
Native form POST with target attribute removed (same-tab navigation, Sec-Fetch-Mode: navigate)
-
fetch() POST with multipart/form-data
-
fetch() POST with application/x-www-form-urlencoded
-
With and without ?appVersion=20260503_0000 on the URL (matches the param all other Data Studio endpoints on the page send)
-
With and without the empty workspaceId and region form fields
-
XSRF token fresh from the Angular-injected form each attempt (so not a token expiry issue)
Not account-specific. I shared the data source in editor mode with a second Google account and ran the copy from that account — identical 400 / code 3 response. The failure travels with the data source (or with the endpoint globally), not with the user session.
Timing matches the rename. This started for me around the Looker Studio → Data Studio transition. The page still mixes both brand identifiers in places (e.g. Google Analytics page-view hits send dt=Looker Studio while the URL is datastudio.google.com), which suggests the migration is partly incomplete. My best guess is that this endpoint either lost a required parameter or had a stricter validation rule introduced backend-side, without the Angular front-end being updated to match.
Affected endpoints I can confirm: copyDatasourceAndRedirect (my case) and copyReport (the original post in this thread, and the related “Looker copy report not working” thread from April 2). Likely a shared codepath.
Happy to share the exact request headers, the Angular form HTML, or anything else useful if a Googler picks this up. Thanks!
