Today, CAP is making upgrades to all of its history instances (also called Root Bucket canisters) to add architecture to accept batch transactions. We’re also updating CAP’s Rust SDK to make batch transactions easy with new failure resistant methods. This means no need to worry or handle CAP insert errors anymore!
All of the Root Buckets that are operated under CAP by external canister owners have received upgrades to add the
insert_many method to their interface.
This means that 1 inter-canister call is no longer restricted to a single transaction insert.
insert_many to make batch transactions by passing an array of transactions to your dApps history instance (Root Bucket).
We’re adding failure resistant transaction insertions to the CAP Rust SDK through the use of new methods
Any errors that arise using these two new methods (eg: a canister out of cycles error) are handled by the method itself. Failed transactions are indexed and saved into the canisters heap memory. When a new transaction is inserted with an old transaction in memory, the backlog is flushed out and bundled with the original transaction into a new batch transaction. Multiple failures grow the indexed backlog, preserving the integrity of your dApps tx history!
Additionally, since both of these methods handle errors for you, they do not need to
await a response, making your canister even faster.
Want to handle errors yourself? You can still use
insert_many to make normal batch transactions without having to wire up a connection to your root bucket yourself.
The CAP team’s expertise is in Rust, not Motoko. If you’re a Motoko expert & would be interested in extending CAP’s Motoko SDK, please reach out to us on Discord!