Summary
Pointing a PAPI-based browser dApp (Hydration UI) at a forklift fork killed the forklift process within ~1 minute: the wasm executor hit RuntimeError: unreachable and the process exited. There is no error isolation — one failing runtime call takes down the whole fork and every connected client.
Environment
@polkadot-api/forklift 0.4.1 (@acala-network/chopsticks-executor 1.5.0)- Node.js v25.7.0, Linux
- Source chain: Hydration-based devnet (Polkadot-SDK parachain with pallet-evm)
Repro
forklift wss://<hydration-endpoint> --port 18099- Point the Hydration UI (or any dApp that fires dozens of concurrent
chainHead_v1_call / chainHead_v1_storage requests on load) at ws://localhost:18099
- Within ~60s:
RuntimeError: unreachable
at wasm://wasm/00b8538a:wasm-function[101]:0x976d8
at wasm://wasm/00b8538a:wasm-function[143]:0xe1c88
at wasm://wasm/00b8538a:wasm-function[110]:0xa1050
at wasm://wasm/00b8538a:wasm-function[710]:0x17bb57
at wasm://wasm/00b8538a:wasm-function[1516]:0x1b538f
at wasm://wasm/00b8538a:wasm-function[1626]:0x1b5fef
at wasm_bindgen__convert__closures_____invoke__h374ab0d2ab71a4a8 (.../@acala-network/chopsticks-executor/dist/esm/chopsticks_executor.js:575:10)
at real1 (.../chopsticks_executor.js:706:22)
The crash was not reproducible on every run — a second attempt with the same workload stayed up (but answered only ~113 of 628 chainHead_v1_call in 60s, which looks like #5, since this UI's runtime calls iterate large storage maps).
Expected
A failing/aborting runtime call should fail that one operation (operationError on the chainHead subscription), not exit the process. For comparison, chopsticks catches executor worker errors and keeps serving (AcalaNetwork/chopsticks#910-era hardening).
Happy to run a patched build against the same workload if useful.
Summary
Pointing a PAPI-based browser dApp (Hydration UI) at a forklift fork killed the forklift process within ~1 minute: the wasm executor hit
RuntimeError: unreachableand the process exited. There is no error isolation — one failing runtime call takes down the whole fork and every connected client.Environment
@polkadot-api/forklift0.4.1 (@acala-network/chopsticks-executor1.5.0)Repro
forklift wss://<hydration-endpoint> --port 18099chainHead_v1_call/chainHead_v1_storagerequests on load) atws://localhost:18099The crash was not reproducible on every run — a second attempt with the same workload stayed up (but answered only ~113 of 628
chainHead_v1_callin 60s, which looks like #5, since this UI's runtime calls iterate large storage maps).Expected
A failing/aborting runtime call should fail that one operation (
operationErroron the chainHead subscription), not exit the process. For comparison, chopsticks catches executor worker errors and keeps serving (AcalaNetwork/chopsticks#910-era hardening).Happy to run a patched build against the same workload if useful.