CDN v1/ decoders failing with errors

[donmccurdy]

I've started seeing errors from projects and packages depending on (unpinned) v1 decoders from the CDN:

• https://gltf.pmnd.rs/ (fails to decode glTF+Draco meshes)
• https://github.com/theatre-js/theatre (examples don't build)

Projects pinned to 1.4.x appear to be fine. Does 1.5.x contain known breaking changes (I didn't find any in the changelog), or is this a possible regression?

Test model:
Avocado-v1.glb.zip

[donmccurdy]

Seeing different error output with different models. Examples:

RuntimeError: memory access out of bounds
    at 001125b2:0x21e79
    at 001125b2:0x3131e
    at 001125b2:0x27722
    at 001125b2:0x30796
    at 001125b2:0x30968
    at 001125b2:0x219d3
    at 001125b2:0x2467d
    at 001125b2:0x2a3c3
    at a._emscripten_bind_Decoder_DecodeBufferToMesh_2 (464786b0-0689-475b-94e9-2bc36832555c:73:329)
    at m.DecodeBufferToMesh.m.DecodeBufferToMesh (464786b0-0689-475b-94e9-2bc36832555c:114:326)

Error: THREE.DRACOLoader: Decoding failed: Failed to decode geometry data.
    at 44e7c927-e4c3-4675-896b-74543d0cb7df:121:1216
    at 44e7c927-e4c3-4675-896b-74543d0cb7df:121:1777

[tomfinegan]

Tagging this a duplicate of #751 until there's some information to lead us to believe it's a new problem. We have kept #751 pinned and open just for this reason.

Please don't use the v1 links-- due to (we think) edge caching of some of the javascript files we end up with mismatches at runtime that produce errors that are difficult to debug and cannot be reproduced with the pinned releases.

[tomfinegan]

FWIW I am able to reproduce the failure (with the above stack) using your test file. Does this issue reproduce if you point your page directly at v1.5.2 files?

[donmccurdy]

Sounds very similar to the previous issue, yes – I don't have direct control of the affected projects, so would need to set up something new pointed to the v1.5.2 files. Will work on a demo when I get the chance here. 👍

[kfarr]

This was also reported on A-Frame Slack by another user:

Just spent a while trying to understand why my working project suddently stopped working. tl;dr : this started 404'ing https://www.gstatic.com/draco/v1/decoders/ ... Might be affecting others. Guess I'll start hosting them with my project 🤷

URLs that previously resolved now show 404 including ones on the readme of this project such as
https://www.gstatic.com/draco/versioned/decoders/1.4.1/*

[tomfinegan]

This was also reported on A-Frame Slack by another user:

Just spent a while trying to understand why my working project suddently stopped working. tl;dr : this started 404'ing https://www.gstatic.com/draco/v1/decoders/ ... Might be affecting others. Guess I'll start hosting them with my project 🤷

URLs that previously resolved now show 404 including ones on the readme of this project such as https://www.gstatic.com/draco/versioned/decoders/1.4.1/*

Can't explain the 404s occurring at any point-- I suspect that's a transient error of some sort. The 1.4.1 and v1 links in the README are both currently working. Again, as stated in the README for the past few releases:

PLEASE DO NOT USE THE v1 URLS. USE THE PINNED RELEASES.

[tomfinegan]

Sounds very similar to the previous issue, yes – I don't have direct control of the affected projects, so would need to set up something new pointed to the v1.5.2 files. Will work on a demo when I get the chance here. 👍

I'm not sure if https://gltf.pmnd.rs/ has been updated to use the pinned files: it is working properly now, however. I suspect propagation of 1.5.2 through the v1 links has completed, or at least has gotten much further along.

[donmccurdy]

Yeah, https://gltf.pmnd.rs/ is not using pinned files but it does appear that 1.5.2 has propagated further since everything works now.

One suggestion — although I'm not sure if this is possible with gstatic hosting? — would be to create HTTP 302 redirects from the v1 URLs to the latest pinned version, instead of serving the files directly on the v1 URLs. In that case any difference in cache timing for .js and .wasm resources would be irrelevant and updates should propagate as expected.

[tomfinegan]

Closing this and leaving the original pinned issue for visibility.

@donmccurdy We are investigating your suggestion and a few other potential solutions to the v1 URLs issue. Thanks!