BUG: Since upgrading to dfx v0.12, running into "Failed to install wasm. The replica returned an HTTP Error: Http Error: status 413 Payload Too Large"

image

Used to work fine till v0.11.2

Thoughts?

1 Like

Running into the same thing after upgrading.

What canister type are you using? There shouldn’t have been any changes that make wasms larger… Unlikely, but are you using "shrink" : false, in your dfx.json?

Not using "shrink": false.

Here’s a screenshot of running the exact same install script now downgraded to v0.11.2

image

Works fine and completes installing canisters

Can also confirm that shrink ran when running the install script on dfx v0.12. Here’s a screenshot:
image

1 Like

Didn’t set any canister type specifically.

Here’s the steps that I did:

  • ran dfx upgrade
  • upgraded successfully
  • rm -rf the .dfx and target folders in my project directory
  • removed the "networks" entry from dfx.json
  • ran dfx start and successfully started replica
  • ran the canister install script to get the attached error
1 Like

Thanks for the details. Since you mention the target folder: Is it a Rust project?

Yes, it’s a rust project

1 Like

Have you inspected the canister wasm modules before and after dfx upgrade?
Did dfx v0.11.2 produce much smaller wasm than dfx v0.12.0?

I just checked.

Here’s with dfx v0.11.2
image

Here’s with dfx v0.12.0
image

This is in the /target/wasm32-unknown-unknown/release folder

@lwshang

In short, for wasm size optimization, dfx v0.11 ran ic-cdk-optimzer while dfx v0.12 ran ic-wasm shrink. The later one currently could not produce the same optimization as before.

This is a known limitation of ic-wasm shrink. We want to improve it to unblock more use cases like yours.

For a short-term workaround, could you either keep using dfx v0.11 or change your canister to custom type and run ic-cdk-optimizer in build script?

Yes, we have currently downgraded to v0.11.2.

But eagerly waiting to upgrade to v0.12 to try out the juicy new things like dfx nns and all :sweat_smile:

Any updates on this?

We have just started running into the wasm size limitation on dfx v0.11.2 as well, as our canisters grow further.

Are there any plans to enable canisters larger than 2MB to be uploaded on the IC?

Looks like we are currently 1kb over the size limit

We have the same issue, unfortunately the only thing I can recommend for now is to gzip your wasm before uploading. it reduces the wasm size 2-5/3 times in size.

This works on dfx v0.11.x as well?

if your question is to gzip, then yes :slight_smile:

1 Like

Thank you for the inputs @Gabriel

What do the steps look like on your end?

My build steps look like this

dfx canister create --no-wallet backend_canister
dfx build backend_canister
dfx canister install backend_canister
dfx generate backend_canister

There are steps in between but this is the simplified version.

And my dfx.json has an entry like this:

"backend_canister": {
  "type": "rust",
  "package": "backend_canister",
  "candid": "./canister/backend_canister/can.did",
  "declarations": {
    "output": "./web-client/declarations/backend_canister"
  }
}

Any changes required here?

Appreciate the inputs :slight_smile:

Hey, sorry for the late answer

You can use this dfx deploy with gzip · Issue #2357 · dfinity/sdk · GitHub

I don’t have a full example yet but working on it, I’ll share as soon as possible.

No worries, I figured it out. It’s quite straightforward.

For future readers, the way to do it is to run gzip right after the build step. DFX picks it up automatically. Like this:

dfx build <canister_name>
gzip -f -1 ./target/wasm32-unknown-unknown/release/<canister_name>.wasm

oh, that’s a neat way, but I would rather have dfx automatically gzip instead of running an extra command that I might forget about it hah.

Also, did gzip fixed your issue?

2 Likes

Yeah, they are significantly smaller now. I was even able to upgrade to dfx v0.12 due to this. These are my wasm sizes now
image

1 Like