TX build in 1.9.0 not respecting 16kb TX limit?

[BenElferink]

Summary

When trying to build a TX that surpasses the 16kb memory limit per TX, I expect an error.

---

In versions 1.7.0 - 1.8.14 of the Mesh SDK, I would get this error message:

txBuildResult error: JsValue("Maximum transaction size of 16384 exceeded. Found: 19226")

In older versions of the Mesh SDK, I would get this error message:

[Transaction] An error occurred during build: Maximum transaction size of 16384 exceeded. Found: 21861.

These errors were very important for my SAAS, as I would perform batching-calculations based on the max and current memory units from the error message.

However, in the latest versions of the Mesh SDK (1.9.0 or higher), I would get this error instead (which breaks my entire SAAS):

Not enough funds to satisfy outputs

After attempting to send a token to even less than 10 wallets I get this error which I do not understand:

Insufficient funds to create change output with tokens

---

EDIT:

After further trial and errors, I've come to new conclusions...

These errors stop showing up after attempting to build the same TX from a clean wallet:

Not enough funds to satisfy outputs
# AND
Insufficient funds to create change output with tokens

But I noticed something big changed, I'm not sure if it's a bug or a new feature.

In previous versions, batching TXs that fit within the 16kb TX limit usually averaged at 250 wallets per TX (if sending only ADA), the latest version of Mesh creates a TX with even 600-700 wallets in it. I did not sign, so I do not know if it will submit successfully, but this is definitely not the expected outcome.

---

Is it possible to bring back the max and current memory units for the error message? Alternatively is there a way to pre-calculate current memory before running tx.build()?

Thanks in advance.

Steps to reproduce the bug

1. Install Mesh @ v1.9.0-beta.28
2. Build a TX that includes over 300 receiving wallets (output should be a token for heavier memory)
3. See error message from tx.build()

Actual Result

Expected Result

SDK version

1.9.0-beta.28

Environment type

• [ ] Node.js
• [x] Browser
• [ ] Browser Extension
• [ ] Other

Environment details

No response

[HinsonSIDAN]

Since V1.9, we changed the default tx builder to core-cst, a pure typescript lib. Perhaps we dont have this logic gate in tx size at the moment, we can add it to backlog for pending implementation.

Meanwhile, if you want to have the same dev-exp as v1.8, you can switch to the wasm core-csl

import { CSLSerializer } from "@meshsdk/core-csl"

const txBuilder = new MeshTxBuilder({
  serializer: new CSLSerializer(),
});

[BenElferink]

Perfect thank you! 🙌

[BenElferink]

Actually, I should have mentioned this is for client-side, the serializer can't be used in browser:

const tx = new Transaction({
  serializer: new CSLSerializer(),
  initiator: wallet,
})

./node_modules/@sidan-lab/whisky-js-nodejs/whisky_js.js:39754:1
Module not found: Can't resolve 'fs'
  39752 |
  39753 | const path = require('path').join(__dirname, 'whisky_js_bg.wasm');
> 39754 | const bytes = require('fs').readFileSync(path);
        | ^
  39755 |
  39756 | const wasmModule = new WebAssembly.Module(bytes);
  39757 | const wasmInstance = new WebAssembly.Instance(wasmModule, imports);

https://nextjs.org/docs/messages/module-not-found

[HinsonSIDAN]

This is something to do with the wasm configuration for your frontend. Mesh website was in wasm build and it worked fine - https://github.com/MeshJS/mesh/blob/main/apps/playground/next.config.js (the commented line). Check if your frontend framework needs special treatment for wasm.