[Web] Model returning Float32Array result fails to build a Tensor

[adam-harwood]

Describe the issue

I am running inference on an ONNX model using onnxruntime-node. The model runs fine against onnxruntime-web. When run on Node (as Javascript, not Typescript), I receive the following exception from session.run():

A float32 tensor's data must be type of function Float32Array() { [native code] }

The error is being thrown from this line.

I have stepped through with the debugger, and found that the data looks like this:

I believe this object should pass the check on this line. It doesn't though, and falls through to throwing an error.

I believe the issue here is the way that type checking is done on Float32Arrays in Javascript. I don't think you can compare the prototype like that, since they're constructed from functions, so instead should be done against the constructor attribute. I suspect it currently only works in Typescript?

If you can confirm this is right I'm happy to open a PR to check both prototype and constructor, but would like some guidance first. The change to make I think would be to change this line from:

} else if (arg1 instanceof typedArrayConstructor) {

to

} else if (arg1 instanceof typedArrayConstructor || arg1.constructor.name === typedArrayConstructor.name) {

To reproduce

I can't provide the model, but I suspect using onnxruntime-node with any model that produces a Float32Array result will cause the issue.

Urgency

This issue blocks us (Guru) from launching a significant feature.

ONNX Runtime Installation

Released Package

ONNX Runtime Version or Commit ID

1.15.1

Execution Provider

Other / Unknown

[fs-eire]

I cannot reproduce this issue. Could you share your JS code ( not model ) so that I can try?

[fs-eire]

the code if (arg1 instanceof typedArrayConstructor) in the context is same to if (arg1 instanceof Float32Array). If arg1 is created by either new Float32Array(...) or Float32Array.from(...), this condition should always be true. I need to know how this error happens - my guess is that there is a library that polyfills Float32Array so that the code takes different Float32Arrays between creating instance and performing this check.

[adam-harwood]

Wow, so in trying to create the smallest possible repro to send to you, I ended up finding it was surprisingly Jest that is the culprit. I'm not the first person to hit the issue, and specifically around the onnxruntime.

The workaround listed there didn't work for me, so I ended up mocking Array.isArray in my Jest test to make it work. Posting here in case any future travellers hit this:

    const originalImplementation = Array.isArray;
    Array.isArray = jest.fn((type) => {
      if (type.constructor.name === "Float32Array" || type.constructor.name === "BigInt64Array") {
        return true;
      }

      return originalImplementation(type);
    });

Thanks for the help @fs-eire!

[sqs]

@adam-harwood: Thank you! Your workaround also fixes the same issue in Vitest for me when using the vmThreads pool.

[Marviel]

Wow, so in trying to create the smallest possible repro to send to you, I ended up finding it was surprisingly Jest that is the culprit. I'm not the first person to hit the issue, and specifically around the onnxruntime.

The workaround listed there didn't work for me, so I ended up mocking Array.isArray in my Jest test to make it work. Posting here in case any future travellers hit this:

    const originalImplementation = Array.isArray;
    Array.isArray = jest.fn((type) => {
      if (type.constructor.name === "Float32Array" || type.constructor.name === "BigInt64Array") {
        return true;
      }

      return originalImplementation(type);
    });

Thanks for the help @fs-eire!

// @ts-ignore
Array.isArray = jest.fn((type) => {
  if (type.constructor && (type.constructor.name === "Float32Array" || type.constructor.name === "BigInt64Array")) {
    return true;
  }

  return originalImplementation(type);
});

Had to make a slight modification.