Problem
Hyperlight-JS snapshot compatibility currently validates only module and
function names.
Typed Rust callbacks are erased to a JSON bridge during registration, while
JavaScript callbacks are inherently dynamic. Hyperlight therefore sees only
the fixed CallHostJsFunction bridge signature and cannot verify that logical
functions such as database.query retain compatible argument and return
semantics.
Rust TypeId is process-local and type_name() is not a stable serialized
contract. Neither reliably describes Serde JSON representation.
Proposed solution
Allow host-function registration to include an explicit stable contract ID or
versioned schema, for example:
database.query: database.query/v1
Persist this identifier alongside each module/function name in snapshot
metadata and compare it during persistent and in-memory restoration.
Functions without a contract retain current name-only validation for backward
compatibility.
Problem
Hyperlight-JS snapshot compatibility currently validates only module and
function names.
Typed Rust callbacks are erased to a JSON bridge during registration, while
JavaScript callbacks are inherently dynamic. Hyperlight therefore sees only
the fixed
CallHostJsFunctionbridge signature and cannot verify that logicalfunctions such as
database.queryretain compatible argument and returnsemantics.
Rust
TypeIdis process-local andtype_name()is not a stable serializedcontract. Neither reliably describes Serde JSON representation.
Proposed solution
Allow host-function registration to include an explicit stable contract ID or
versioned schema, for example:
database.query: database.query/v1Persist this identifier alongside each module/function name in snapshot
metadata and compare it during persistent and in-memory restoration.
Functions without a contract retain current name-only validation for backward
compatibility.