Thanks for feedback. Opened new thread at:
Heap out of bounds, error code Some(“IC0502”) on C++ code run - Developers - Internet Computer Developer Forum (dfinity.org)
Is there a branch of the sdk that I could use locally to build dfx? I just started trying to get the Node.js APIs working more deeply in Azle and I was immediately hit by the limit, it would be great to at least work locally while awaiting the feature.
I think @AdamS should be able to give you info on if that’s available.
It would be great to have a version of dfx without any limits (app size, heap, etc…) that could be used for testing locally (or maybe a flag when running dfx). It would be useful in figuring out whether some of the issues rising is due to limitation!
@AdamS any branch available for this?
Not at the moment. The feature is not live on mainnet yet.
Sorry, to clarify, I’m even just looking to deploy locally with a local branch of dfx, even if not live on mainnet
Any update on when this is coming out? We’re trying to get node packages working in Azle, was making great progress on sql.js when we were slapped with this limit
@AdamS’s PR to dfx was just merged, it’ll be in the next release. I think we target the end of next week for that
This is amazing news!!! I just tested this locally this morning and was able to deploy a ~14 MiB binary…and get SQL.js to work in Azle!
Great job everybody who worked on this, so awesome!
So what are the next steps and timeline to finally getting this on mainnet? Is it on mainnet yet? dfx 0.16.0 has the feature, but there is this major bug: DFX 0.16.0 is now promoted - #2 by lastmjs
No worries, Jordan. The large Wasm support is enabled in this release, so it should be rolled out ~next week.
Thanks for reporting the bug, it was also fixed today. There must be a new dfx release soon, we’ll keep you informed.
Hey 
, I tried using dfx version 0.16 and still faced an issue. I have an update function that looks like below:
#[ic_cdk::update]
#[candid_method(update)]
pub async fn upload_wasms(wasm_type: WasmType, wasm: Vec<u8>) -> Result<String, String> {
CANISTER_DATA.with_borrow_mut(|canister_data| {
canister_data.wasms.insert(wasm_type, Blob::from_bytes(Cow::Owned(wasm)));
});
Ok("Success".into())
}
These function is used to upload wasm which would be later used to create canisters on the fly. But using these function to upload wasm still results into error:
The replica returned an HTTP Error: Http Error: status 413 Payload Too Large, content type "text/plain", content: Request 0xfb5f0a8564d092d0225c8d30fceb45adf4bccc8a3bb970eab30fe0ee16af7679 is too large. Message byte size 2152499 is larger than the max allowed 2097152.
Hey @gravity_vi this is not the correct way to use this feature. You have defined a regular update method which is still bound by the regular 2MB message limit.
In order to achieve what you want, you’d have to use a combo of the provided upload_chunk and install_chunked_code apis on the management canister that will allow you to upload the Wasm in chunks, store it in the canister that will create the others and then install the code when you need it.
@dsarlis Thanks for the quick response. I had one more question. I am planning to add a generic proposal that would take wasm and upgrade other child canisters. Will this mechanism for that use case as well. Also How do we handle sending wasms in inter canister call?
I am planning to add a generic proposal that would take wasm and upgrade other child canisters.
The underlying mechanism should work. However, using proposals adds another layer on top of the current mechanism which would need some thought to get it right. I believe the NNS team is also planning to use this feature at some point for NNS canisters and also SNS canisters. It might be a good idea to sync with them to align on an approach.
Also How do we handle sending wasms in inter canister call?
Can you elaborate what exactly you have in mind here?
Can you elaborate what exactly you have in mind here?
The wasms received in generic proposal in the top level canister can we send it to other canister using chunking mechanism?
The wasms received in generic proposal in the top level canister can we send it to other canister using chunking mechanism?
You’d have to build that yourself, sending to another canister would be bound to the 2MB message limit. You don’t have to send it around though to install canisters. You can install to another canister on the same subnet through install_chunked_code as long as the Wasm is present in the top level canister.
PS: There is a bigger bound (10MB) for same subnet inter-canister requests but we actually plan to remove it since it’s main use case was to allow installations of larger Wasm modules before the feature we are discussing in this thread was introduced.
Alright. I will try it out. Thank you so much @dsarlis 
Has anyone got an example of doing this in motoko??? I am not sure what to pass for the wasm_module_hash parameter