oddsdk
Tsize too large for encoding
Uncaught (in promise) Error: Tsize too large for encoding
at P5e (auth.fission.codes/web_modules/ipfs.min.js:82:80571)
at Jk (auth.fission.codes/web_modules/ipfs.min.js:82:81023)
at Object.st (auth.fission.codes/web_modules/ipfs.min.js:82:85218)
at n (auth.fission.codes/web_modules/ipfs.min.js:82:217569)
at async DAGService.put (auth.fission.codes/worker.min.js:3050:19)
at async Server.handleQuery (auth.fission.codes/worker.min.js:3536:25)
Notes:
- 1 DAG = 1 IPFS Block
- Error comes from js-ipfs, not the dag-pb lib
- https://github.com/ipfs/js-ipfs/issues/2799 (should we manually check if it ever exceeds 1MB?)
Are we using ipfs.size the wrong way? Example: https://github.com/fission-suite/webnative/blob/1d91cb0f30aec80f1ea94f8cbd924e2d3b67feee/src/fs/protocol/public/index.ts#L53
Might be that the DAG isn't too big, but the just Tsize of a link in a DAG.
Looking at the github code search for "Tsize too large for encoding", it seems like this is an error raised from the protobuf library used in @ipld/dag-pb when an encoded integer is a non-safe number: https://github.com/ipld/js-dag-pb/blob/ceee519459e427843412dabd7ac78d4f0b5551f0/src/pb-encode.js#L30
From looking at that code, I think it's totally possible that NaN or undefined may be passed as well and don't make the check.
So it may be that and not that the numbers are > 2^52 or something.
Interesting 🤔 Also strange then that dag-pb doesn't complain beforehand when creating the DAG. Maybe something is going wrong during the transfer with the message ports.
One case where this bug was found was while recovering an account with the Fission Dashboard. After clicking the account recovery link update, the error message occurred just after the "updating data root" log message.
The error occurred in Firefox, but recovery succeeded in Chrome. Only one success, but maybe a browser inconsistency?
The error occurred in Firefox, but recovery succeeded in Chrome. Only one success, but maybe a browser inconsistency?
My theory is the bug is triggered randomly. I've seen it cycle through a bunch of different error messages on reloads, and I've seen it both in Firefox and Chrome. When you reload, is it consistently this error message?
It's not possible to reload in this case because the account recovery challenge appears to be one-time. It is however repeatable in Firefox, over five attempts.
i got this error recently in a for loop that removes all files from a dir. not sure how much context is relevant, but it a directory that has between 0 and 200 files added and deleted several times in the last day
Oh boy. I have a hunch of where this issue comes from: When calculating the DAG size, the size calculator doesn't de-duplicate the DAG. (sorry, DAG here is "Directed acyclic graph", and all IPFS data is actually a DAG, because duplicate data refers to the "same" data). Webnative directories are very... dag-y, since there's lots of structural sharing between versions. So because there's lots of structural sharing, the naive directory size computation is sometimes extremely inflated and probably gets out of bounds for 64-bit floating-point arithmetic, which causes it to fail to encode.
Is this related to https://github.com/fission-codes/fission/issues/603 by chance?
Is this related to https://github.com/fission-codes/fission/issues/603 by chance?
Well, the it's the same kind of issue. But it's computing the DAG size in javascript on the client in this case (which I think the server just takes for granted and reports to users?).