CanCan error: Failed to store video. [TypeError: Conversion from 'BigInt' to 'number' is not allowed.]

Developers
1

Hi
I did some customization to CanCan and now I receive this error message, whic happears at putVideoChunk(videoId, chunk, sliceToNat) call.
It does not even get to the server, and does not even make the http request. I checked all the typings used here and do not see any bigint! anyone has an idea what this is complainting about?

Failed to store video. [TypeError: Conversion from 'BigInt' to 'number' is not allowed.]
2

It is failing at creating args. But there is no BigInt here! I am still cehcking…

arg = IDL.encode(func.argTypes, [videoId, chunk, sliceToNat]);
3

What is the Motoko or Candid type of videoId. If Nat/Int or nat/int that will be a BigInt in JS.

1 Like
4

bingo! chunk number is IDL.Nat.
Do you know what about IDL.Nat8 ?

5

I think I found the issue it is inside idl.js and due to line

const max = BigInt(2) ** BigInt(this.bits);

Here is a detailed explanation of issue:
it shouldn’t turn ** in to Math.pow for BigInt · Issue #13109 · babel/babel (github.com)

I switched that part to jsbi

6

Nat8 should be fine.

@kpeacock do you know what the JS issue with BigInt is? I vaguely remember hearing that react native apps might not work due to lack of JS BigInt support, but perhaps this is a different issue?

1 Like
7

This is a babel issue. Babel is trying to support backwards compatibility before BigInt and breaks. We solved it in CanCan with this: cancan/package.json at main · dfinity/cancan · GitHub

2 Likes
8

@claudio @kpeacock

True, this is different, but on a separate note, I think one of main isseus when implementing Dfinity within a react native project is BigInt on Android right now, which might be addressed soon or not. Is there any plan to switch the BigInt implementations to something like jsbi(which uses native implementation if supported) or are you open to pull requests of that kind or this is someting totally off the road right now?

@jzxchiang suggested a solution of changing the JS engine, however, I am not sure if this is something many developers would be willing to do, considering that performance of Hermes engine(on a plain-to-plain comparisson) is better than all others for react native and has smaller build size, and is an out of the box option for expo.

9

My view of it is basically this:

  1. Eventually, Android will get its act together and support BigInt
  2. Reverting to a non-standard number library would be a breaking change to all agent-js packages and Candid
  3. Native JavaScript features are preferable
  4. Mobile JavaScript support is ideal, but not currently scoped for me to work on

In the short term, re-writing @dfinity/agent seems like a step in the wrong direction. I think that the way we’ve built it is correct for browsers and Node, and will eventually be correct for Native.

In the meantime, I think a viable alternative would be to create new packages addressing the problems in native - BigInt and BLS, and to publish it as @dfinity/agent-native, @dfinity/candid-native, and so on

1 Like
10

Yeah, the separate agent-native, candid-native packages probably make sense. As @ehsan6sha mentioned, changing the JS engine isn’t great, as I do want to be able to use Hermes eventually (not just for performance but also for library compatibility—reanimated v2 depends on it, e.g.).

At least for solving the BigInt problem, maybe we just need to fork off of that commit a couple months ago that switched from using the JS polyfill to the JS native BigInt? Although I’m sure additional code changes happened after that that we will want to incorporate in it… Truly a headache

11

Y’all can get a grant for this, btw

1 Like