Hi.
Hi.
I'm seeing a strange behavior of wasm in DurableObjects, especially when alarms are used. I saw this exception in logs before we were using alarms (when response was synchronous), but now it started happenning very often.
The library used is automerge.
After a DO gets into a "broken state", an exception is raised for any library method call in the code produced by wasm-bindgen:
RangeError: Invalid typed array length: undefined\n at new Uint8Array (<anonymous>)\n at getUint8Memory0
wasm.memory.buffer
if logged is an ArrayBuffer with non-zero byteLength.
The exception logs spikes on wrangler deploy
s (attached screenshot). But happens during the normal execution as well. I don't yet understand how a DO gets into and out (the guess is when it gets recreated in another process (isolate?)) of this state, but once it does it keeps failing on any library operations.
Would appreciate any ideas or hints on what might be the problem.2 Replies
Tried a library update today as some changes were made there with wasm bundling and bindings.
The failure mode is the same except now it seems to be working in alarms but failing during RPCs. 🤔
The issue actually had nothing to do with alarms, large memory allocations is what's bringing a DO into a broken state
https://github.com/yarolegovich/cf-automerge-overload/tree/main
GitHub
GitHub - yarolegovich/cf-automerge-overload
Contribute to yarolegovich/cf-automerge-overload development by creating an account on GitHub.