Confusing ERROR tracing when not actually an error

[ludfjig]

https://github.com/ludfjig/hyperlight/blob/31bfc5a2f54e88d29e29388ac0a908d25f97fc19/src/hyperlight_common/src/flatbuffer_wrappers/guest_error.rs#L199

causes any failures to be logged with ERROR level. However, we use this function unconditionally to check whether an error occured or not here https://github.com/ludfjig/hyperlight/blob/31bfc5a2f54e88d29e29388ac0a908d25f97fc19/src/hyperlight_host/src/func/guest_err.rs#L28

Thus the function returning an Err does not necessarily mean an actual error occured.

The issue can be reproduced by running for example cargo run --package hyperlight-host --example logging and observing the error logs related to "pop_buffer_into". (NOT the executioncancelledbyhost errors)

• The short term fix would be to remove the instrument macro on the functions that unconditionally return an error in the happy code path.
• The long term fix would be to change the way we check if an error occured.

[myadav27]

@ludfjig I can look into this

[ludfjig]

@ludfjig I can look into this

That would be awesome @myadav27

[dblnz]

$ RUST_LOG=error cargo run --example hello-world
   Compiling hyperlight-host v0.6.1 (/home/dblnz/workspace/msft/hyperlight/src/hyperlight_host)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 7.00s
     Running `target/debug/examples/hello-world`
Hello, World! I am executing inside of a VM :)
[2025-06-18T16:39:09Z ERROR hyperlight_common::flatbuffer_wrappers::guest_error] error=Error while reading GuestError: Unaligned { position: 23, unaligned_type: "u64", error_trace: ErrorTrace([TableField { field_name: "code", position: 23 }]) }
[2025-06-18T16:39:09Z ERROR hyperlight_host::mem::shared_mem] error=Error("pop_buffer_into: failed to convert buffer to hyperlight_common::flatbuffer_wrappers::guest_error::GuestError")
[2025-06-18T16:39:09Z ERROR hyperlight_host::mem::mgr] error=Error("pop_buffer_into: failed to convert buffer to hyperlight_common::flatbuffer_wrappers::guest_error::GuestError")

[jsturtevant]

#662 PR is a short term fix. We should not rely on this "trying to deserialize an error" for error handling. Leaving this open so we can address this properly in the future.