Race condition in Cesium3DTileset / Reconsider `readyPromise` pattern

• Paste this into a new file called aTrivialSpec.js into packages/engine/Specs/Scene/.

import { Cesium3DTileset, DeveloperError } from "../../index.js";
import createScene from "../../../../Specs/createScene.js";

fdescribe("trivialSpec", function () {
  let scene;
  beforeAll(function () {
    scene = createScene();
  });

  afterAll(function () {
    scene.destroyForSpecs();
  });

  it("a trivial test", function () {
    const tileset = new Cesium3DTileset({ url: "test.invalid" });
    expect(function () {
      throw new DeveloperError();
    }).toThrowDeveloperError();
    tileset.destroy();
  });
});

• Run the unit tests
• Most of the time it will fail/hang with the below error

$ npm -- run test --browsers ChromeHeadless

> cesium@1.99.0 test
> gulp test --browsers ChromeHeadless

[20:29:15] Using gulpfile ~/Git/CesiumGS/cesium/gulpfile.js
[20:29:15] Starting 'test'...

  trivialSpec
    ✓ a trivial test
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
  An error was thrown in afterAll
  Unhandled promise rejection: Request has failed. Status Code: 404 thrown
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
  An error was thrown in afterAll
  Unhandled promise rejection: Request has failed. Status Code: 404 thrown
0.068 secs: trivialSpec a trivial test
0 secs: Renderer/Buffer fails to destroy: WebGL 2
0 secs: Renderer/Buffer fails to copy a large array view: WebGL 2
0 secs: Renderer/Buffer fails to provide an array view: WebGL 2
0 secs: Renderer/Buffer destroys: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer with index buffers: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer with vertex buffers: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer throws when readBuffer is the same buffer and copy range overlaps: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer throws with one index buffer and the other is not an index buffer: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer throws with invalid sizeInBytes: WebGL 2

Chrome Headless 107.0.5304.110 (Linux x86_64): Executed 1 of 13836 (skipped 156) ERROR (0.02 secs / 0.068 secs)

[20:29:18] Finished 'test' after 2.51 s
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
  Disconnected , because no message in 120000 ms.
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
  Disconnected , because no message in 120000 ms.
0.068 secs: trivialSpec a trivial test
0 secs: Renderer/BuiltinFunctions has czm_transpose (4x4)
0 secs: Renderer/BuiltinFunctions has czm_transpose (3x3)
0 secs: Renderer/BuiltinFunctions has czm_transpose (2x2)
0 secs: Renderer/AutomaticUniforms can declare automatic uniforms
0 secs: Renderer/AutomaticUniforms has czm_viewport
0 secs: Renderer/AutomaticUniforms has czm_viewportOrthographic
0 secs: Renderer/AutomaticUniforms has czm_viewportTransformation
0 secs: Renderer/AutomaticUniforms has czm_globeDepthTexture
0 secs: Renderer/AutomaticUniforms has czm_model

• It seems to happen more often with npm -- run test --browsers ChromeHeadless, but since it’s a race condition it’s hard to say why.

I’m fairly certain what’s happening is that Cesium3DTileset has an async code path that keeps running, even after destroy is called (and therefore after the test is finished). In 99.99% of the times I’ve seen this error from karma/jasmine, that’s always been the case in general.

[ggetz]

In general, the entire readyPromise approach is actually a bad abstraction that’s may become a larger problem in modern systems, with unhanded promise detection detecting a failed readyPromise as a critical error unless someone awaits it.

Cesium seems to have unhandled promise failures sprinkled throughout the code, largely because of the flawed readyPromise convention that does not match modern Promise best practices.

I do agree that this is a fundamental problem that needs fixing. I think this is alluded to in a few other issues, but does not have its own, so we can use this one to track it.

[javagl]

When reviewing the handling of promise chains and catch usage, one might want to have a look at the Viewer#updateZoomTarget function. It has two very similar code blocks for the zoom target being a Cesium3DTileset or a TimeDynamicPointCloud, with the latter omitting a

      .catch(() => {
        cancelZoom(viewer);
      });

that is present in the former. (Omitting this may or may not be intentional, but that could be part of the review - maybe the code block could be moved into a method to handle both target types equally…?)