IPFS - Maximum call stack size exceeded

Hey,
A user of mine found a really odd error.

When he tried to upload a specific image it returned the error “Maximum call stack size exceeded”

The way it works is, the image is sent to the cloud functions and we upload it through there because we like to do some verifications before adding it to the app.

The cloud function code is simply:

const image = request.params.image;
const imageArray = image.split(",");
const imageBase64 = imageArray[1];
const fileToSave = await Moralis.Cloud.toIpfs({
    sourceType: "base64Binary",
    source: imageBase64,
});

Image that returns the error: https://i.ibb.co/6v4BPrW/1.png

How did you pass image data in the parameters?

Send it directly,

let reader = new FileReader();
reader.readAsDataURL(file);
reader.onload = () => {
    const imageToSend = reader.result; // <-- this is what I send
}

I think you can only send strings in the parameters. Try converting the image to base64 and send the base64 string as parameter.

It is already a string and it works in 99.9% of cases. Only this specific one it fails. Even if it was a client side issue I would like to fix this server side because this error is making the CPU stuck at 100%

any chance it could be due to data size?

Did you try with larger file sizes than the attached and got it worked?

100% sure it’s not a size issue, the img has only 4mb and yes it uploaded 3x the size

Usually, you get that error when the wrong type of data is sent, like a variable instead of a value.

Can you add some logging? Like logging the size of the sent data?

1 Like

I have a limit of 8mb before the upload so I know the size isn’t the problem.
Either ways I printed out the actual size.
5799702 ~= 5MB

ok, and that data makes it to the cloud function, an the cloud function gives that particular error?

1 Like

Exacly that yes,

The line that fails is the one that tries to upload the file to the IPFS

const fileToSave = await Moralis.Cloud.toIpfs({
    sourceType: "base64Binary",
    source: imageBase64,
});

ok, got it, I’ll have to test it today/tomorrow to see how it repicates

that link (https://i.ibb.co/6v4BPrW/1.png) points to a ~4MB file

1 Like

Oh mb, 5799702 is the number of chars in the string, I usually calculate the size by multiplying by 3/4. ~= 4349776 bytes ~= 4.1483 Megabytes

That’s the correct image and the size on the client is exactly the same when it reaches the server

I get a smaller size for the original file and also for the base64 encoding, maybe you also have the file name there?

If you’re getting 4349760 then that’s the true size, 4349776 is just an estimation

I was able to reproduce the error

1 Like

Awesome, now the hard part comes, why is it happening

Hey again,
Have you got any news about this issue?

I don’t know yet. It looks to be related to a library that checks that base64 buffer. You could try to use upload folder functionality from web3api as an alternative.

Hey @cryptokid!

Just wanted to know if we should start using the “upload folder” functionality everywhere instead of the “original” way or if it’s going to get fixed at some point!