Setup and Style Pane have no interface for charts using a specific source

[HankinsonC]

 This issue started happening on Friday, 6/22. I have also verified with coworkers using different browsers and operating systems that this error occurs for them as well. 

I am using a source connected through the Google Sheets connector. It has been in use for over one year and is updated daily via python. It is aprox. 80 cols by 35k rows. It has 14 calculated fields and one parameter.

Across all reports using this (reusable) source, we are now unable to change settings for ALL existing and new charts using this source. We are presented with a blank user interface instead of the usual options. We do not receive additional/formal errors and the only indication of a problem is the blank interface. Existing charts display data correctly. 

We attempted to triage the issue by duplicating the source, deleting the original, and connecting to the copy. However, the issue remains when connecting to the copy. 
If we are to connect to the raw source anew, the error does not occur. However, dozens of charts and controls across multiple existing reports are connected to the main/existing reusable source. 

See below for errors shown in the browser's console when accessing these charts:
DevTools failed to load source map: Could not load content for https://meet.google.com/chrome.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load source map: Could not load content for https://ogs.google.com/u/0/chrome.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
VM57:371 Uncaught ReferenceError: structuredClone is not defined
at <anonymous>:371:421
at <anonymous>:70:211
at <anonymous>:70:237
at Object._.lg_Sa (m=pm_base:143:356)
at m=sye,syd,syf,sy14,sy15,syc,sy1b,sy1c,sy1d,sy9,syn,sy7,syx,sy2,sya,syp,syo,sy19,sy1e,sy8,sy18,syb,sy1f,sy1g,sym,sy1l,sy4,syj,sy12,sy11,sy1j,sy1k,sy13,sy1m,sy1i,syg,syi,sys,sy1,syv,sy1a,syk,sy10,sy1r,sy1q,sy1h,sy16,sy1y,sy1w,sy3,sy6,syh,syq,syr,syu,syw,syy,syz,syt,sy1n,sy1o,sy17,sy1s,sy1t,sy24,sy1x,sy22,sy0,sy25,sy28,sy2b,sy21,sy2m,sy2n,sy2o,sy2l,sy23,sy2i,sy2p,sy1z,sy1u,sy20,sy2h,sy2j,sy2f,sy2c,sy2v,sy2a,sy2d,syl,sy1p,sy1v,sy26,sy29,sy2e,sy2t,sy2x,sy36,sy3b,sy3c,sy3d,sy3e,sy3f,pm_ng2report:6733:3
at m=sye,syd,syf,sy14,sy15,syc,sy1b,sy1c,sy1d,sy9,syn,sy7,syx,sy2,sya,syp,syo,sy19,sy1e,sy8,sy18,syb,sy1f,sy1g,sym,sy1l,sy4,syj,sy12,sy11,sy1j,sy1k,sy13,sy1m,sy1i,syg,syi,sys,sy1,syv,sy1a,syk,sy10,sy1r,sy1q,sy1h,sy16,sy1y,sy1w,sy3,sy6,syh,syq,syr,syu,syw,syy,syz,syt,sy1n,sy1o,sy17,sy1s,sy1t,sy24,sy1x,sy22,sy0,sy25,sy28,sy2b,sy21,sy2m,sy2n,sy2o,sy2l,sy23,sy2i,sy2p,sy1z,sy1u,sy20,sy2h,sy2j,sy2f,sy2c,sy2v,sy2a,sy2d,syl,sy1p,sy1v,sy26,sy29,sy2e,sy2t,sy2x,sy36,sy3b,sy3c,sy3d,sy3e,sy3f,pm_ng2report:13025:4
(anonymous) @ VM57:371
(anonymous) @ VM57:70
(anonymous) @ VM57:70
_.lg_Sa @ m=pm_base:143
(anonymous) @ m=sye,syd,syf,sy14,sy15,syc,sy1b,sy1c,sy1d,sy9,syn,sy7,syx,sy2,sya,syp,syo,sy19,sy1e,sy8,sy18,syb,sy1f,sy1g,sym,sy1l,sy4,syj,sy12,sy11,sy1j,sy1k,sy13,sy1m,sy1i,syg,syi,sys,sy1,syv,sy1a,syk,sy10,sy1r,sy1q,sy1h,sy16,sy1y,sy1w,sy3,sy6,syh,syq,syr,syu,syw,syy,syz,syt,sy1n,sy1o,sy17,sy1s,sy1t,sy24,sy1x,sy22,sy0,sy25,sy28,sy2b,sy21,sy2m,sy2n,sy2o,sy2l,sy23,sy2i,sy2p,sy1z,sy1u,sy20,sy2h,sy2j,sy2f,sy2c,sy2v,sy2a,sy2d,syl,sy1p,sy1v,sy26,sy29,sy2e,sy2t,sy2x,sy36,sy3b,sy3c,sy3d,sy3e,sy3f,pm_ng2report:6733
(anonymous) @ m=sye,syd,syf,sy14,sy15,syc,sy1b,sy1c,sy1d,sy9,syn,sy7,syx,sy2,sya,syp,syo,sy19,sy1e,sy8,sy18,syb,sy1f,sy1g,sym,sy1l,sy4,syj,sy12,sy11,sy1j,sy1k,sy13,sy1m,sy1i,syg,syi,sys,sy1,syv,sy1a,syk,sy10,sy1r,sy1q,sy1h,sy16,sy1y,sy1w,sy3,sy6,syh,syq,syr,syu,syw,syy,syz,syt,sy1n,sy1o,sy17,sy1s,sy1t,sy24,sy1x,sy22,sy0,sy25,sy28,sy2b,sy21,sy2m,sy2n,sy2o,sy2l,sy23,sy2i,sy2p,sy1z,sy1u,sy20,sy2h,sy2j,sy2f,sy2c,sy2v,sy2a,sy2d,syl,sy1p,sy1v,sy26,sy29,sy2e,sy2t,sy2x,sy36,sy3b,sy3c,sy3d,sy3e,sy3f,pm_ng2report:13025
js?key={KEY REDACTED}=3&callback=loadMapsApiCallback&language=en&region=US&libraries=visualization:230 Google Maps JavaScript API has been loaded directly without loading=async. This can result in suboptimal performance. For best-practice loading patterns please see https://goo.gle/js-api-loading
hca @ js?key={KEY REDACTED}&v=3&callback=loadMapsApiCallback&language=en&region=US&libraries=visualization:230
google.maps.Load @ js?key={KEY REDACTED}&v=3&callback=loadMapsApiCallback&language=en&region=US&libraries=visualization:14
(anonymous) @ js?key={KEY REDACTED}=3&callback=loadMapsApiCallback&language=en&region=US&libraries=visualization:411
(anonymous) @ js?key={KEY REDACTED}=3&callback=loadMapsApiCallback&language=en&region=US&libraries=visualization:411
DevTools failed to load source map: Could not parse content for {MY REPORT BASE URL HERE, Redacted}/firebase-auth-compat.js.map: Unexpected token < in JSON at position 0
DevTools failed to load source map: Could not parse content for {MY REPORT BASE URL HERE, Redacted}/firebase-app-compat.js.map: Unexpected token < in JSON at position 0
DevTools failed to load source map: Could not parse content for {MY REPORT BASE URL HERE, Redacted}/firebase-firestore-compat.js.map: Unexpected token < in JSON at position 0

[sam8 · Accepted solution]

Thank you for sharing all of this information!

It's frustrating that a new source to the same data doesn't have these errors, it makes this much harder to troubleshoot.

I'm curious, when you successfully create the new data source, which console errors remain? This might help us narrow down which ones are specific to the faulty data source. For example, I see the "Google Maps JavaScript API has been loaded directly without loading=async" error on my side too, which makes me think that's not the culprit.

[HankinsonC]

No console errors remain. 

I was later able to restore access by backtracking edits to the source I had made prior. I deleted the parameter I had set up and access to the charts was restored across all reports. 

I am not sure why this resolved the issue, but have posited that it was perhaps a poor choice of parameter name, in absence of a better explanation.