Debugging drawingBufferWidth error

The following is an error that has stumped our development team for a while now… mostly because it seldom occurs, but when it does get triggered, can be quite disruptive:

Our team has some possible insights into the problem, but would love to hear back from the community as to possible triggers as to why this error gets thrown.

We don’t believe this to be a data issue as one of our developers had multiple instances of our web software application up - production, staging, and running their own local developer instance - and to clarify here - our production and staging instances were leveraging the same database but our local is using a dummy data set (a vastly different set of data than what our live database is providing). And at the exact same point in time, all three web applications running on the same computer threw this error.

We have periodic episodes of this error being triggered across a spectrum of computer assets (lower spec machines definitely seem to trigger more often, but nonetheless, even some of our high spec workstations show what we now call, the pink screen of death. And obviously the only resolution we have is to refresh the browser and continue onward which is not an ideal solution. And because of how random this error seems to be, we haven’t found a way to reproduce this.

Cesium Configuration:
We have scanned the forums and have seen a variety of suggestions, but at this point, we feel like were just guessing what the culprit is. One thing we did discover; however, on our end, was the setting of maximumScreenSpaceError. Other forums that had a somewhat similar question stated to bump this value to higher number. According to Cesium’s documentation, the default is set to 16. We don’t believe that is true. In fact, when we explicitly state the maximumScreenSpaceError = 16 versus not stating, we get two completely different results with the tile sets:

Explicitly stating maximumScreenSpaceError = 16.

Not providing maximumScreenSpaceError attribute within our configuration.

We did provide this attribute within our recent deployment of our software (we had it set to an 8) as we found by doing so increased the size of the labeling in the mapbox tiles were leveraging. And this error has been prominent ever since the release, so it definitely makes this suspicious, but it also seems the default value of 16 is not true either. Again, not even sure if this has an impact on the above error.

Any help on this would be greatly appreciated. If there’s any more information we need to provide, please let us know and we will gladly share.

Thanks for taking a look at this!