I ran across this error today and was curious what it was and how to best avoid it. I had a pretty much max DTS transaction run just before this(trying to get an edge case optimized enough to stay atomic and under 40B Instructions:shaking_face:)
Canister call failed: Error from Wasm chunk store: Canister is heap delta rate limited. Current delta debit: 225660928, limit: 78643200.
Use the `stored_chunks` API to check which hashes are present or top up the canister if it is low on cycles. See documentation: https://internetcomputer.org/docs/current/references/execution-errors#wasm-chunk-store-error. Reject code: CanisterError. Error code: CanisterContractViolation. Certified: true
I don’t think it is low on cycles…this is via pocket-ic and I give it a billionty-billion.
The heap delta rate limit caps how much a single canister is allowed to write to its state, both to protect the health of the overall subnet and for fairness with regards to other canisters.
If you write a lot in one transaction, messages in the next few rounds can get shed. You can just retry a few seconds later, when your canister gets some of its heap delta allowance back. In pocket-ic, you can also add a few dummy rounds to simulate that.
Is my transaction thrown out, or I just have to chill for a bit?
I think it’s rejected. Was it a call to upload_chunk? You’ll have to retry, or if it’s several calls in a loop then consult stored_chunks like the error says, to find out which chunks made it.
None of that sounds like my code…hmmm…the next test in my suite probably reuploads the canister to get a fresh baseline.
I guess the question I want to ask is, will the transaction that causes the disparity be rejected…or am I basically waiting for it to settle? I don’t think it failed because my test ended up passing and I resolved this by adding a bunch of pic.js ticks after my main function call that is being tested…but I wanted to confirm that there wasn’t some kind of hidden heap trap->rollback in addition to the instruction limit.