InvalidData("tried to read 32 bytes from response but only had 16 remaining!")

Hello everyone!

I’m facing an issue with my Rust code while building on Sway and testing smart contracts. Sometimes, I encounter this error:

thread 'local_tests::liquidate_test::liquidate_test' panicked at tests/local_tests/
called `Result::unwrap()` on an `Err` value: InvalidData("tried to read 32 bytes from response but only had 16 remaining!")

This error seems to occur randomly and is not related to any specific part of my code. Surprisingly, removing a couple of unused lines seemed to fix it, but I’m not entirely sure why.

Has anyone else experienced a similar issue or can shed some light on the nature of this error? Any insights would be greatly appreciated! Thanks.


What version of the Rust SDK are you using?

Hi there!

We had a very similar case where someone stated that deleting unused lines would fix the problem. Turns out the issue was caused by a sporadic empty response from the client.

The fix was introduced shortly before v0.41.0 (right now we are on 0.52) so this seems like a really edge case and additionally to your sdk version, we might require to check your code in order to replicate and dive deeper.


1 Like

Default host: aarch64-apple-darwin
fuelup home: /Users/alexey/.fuelup

installed toolchains

beta-4-aarch64-apple-darwin (default)

active toolchain

beta-4-aarch64-apple-darwin (default)
forc : 0.46.1
- forc-client
- forc-deploy : 0.46.1
- forc-run : 0.46.1
- forc-doc : 0.46.1
- forc-explore : 0.28.1
- forc-fmt : 0.46.1
- forc-index : 0.23.0
- forc-lsp : 0.46.1
- forc-tx : 0.46.1
- forc-wallet : 0.3.0
fuel-core : 0.20.5
fuel-core-keygen : Error getting version string
fuel-indexer : 0.23.0

fuels versions

forc : 0.45
forc-wallet : 0.45

Thanks for sharing, what about the fuels-rs version?

we have this one 0.49.0

This looks like an edge case.

Can we get more information on the call that’s panicking?

so, we have a system of 6 contracts

Here is a function that fails with the error “tried to read 32 bytes from response but only had 16 remaining!”

on that like we are calling another contract perp_market_contract

  let order_id = perp_market_contract.open_order(trader, base_token, base_size, order_price);

open order in perp market looks like that perp_market_contract

we have used let market = get_market(base_token); a few times ago but rn we don’t need it here, and now we are having an error after removing that line:

let market =  get_market(base_token); 

btw open order in the perp market returns some b256 and after open order from the clearing house returns it as well, but the result on rust SDK is not the same as the value in storage (or even if we log that value)

rn I tried to run that open_order from perp market and the error is still the same

but it works if I do it like that

here is get_market func btw


  • public_contract.open_order is the public function, gets the perp_market_contract and invokes the perp_market_contract.open_order function.

  • The perp_market_contract.open_order function panics with InvalidData(“tried to read 32 bytes from response but only had 16 remaining!”)

  • The perp_market_contract.open_order function calls the get_market helper.

  • The perp_market_contract.open_order function returns a b256

  • Removing everything from the perp_market_contract.open_order function and just returning ZERO_B256 panics with InvalidData(“tried to read 32 bytes from response but only had 16 remaining!”)

  • Removing everything from the perp_market_contract.open_order function, but keeping the get_market helper, works as expected.

  • The get_market helper instantiates the clearing_house_contract and invokes the clearing_house_contract.get_market method.

Does this interpretation corresponds with the described issue? @fuel , in that case, this is a quite edgy case.

Requesting some help from @mujkica

1 Like

in perp_market order_id is calculated as the hash from price, trader address, and asset, this id returns function perp_market.open_order, and then it returns clearing_house.open_order, if you remove -> b256 the problem disappears, maybe it is somehow connected with the problem that the result of calling open_order in the rust sdk differs from the value in storage

I’ve spent some time trying to reproduce this, including setting up a chain of multiple contracts, storage manipulations etc. but couldn’t get the same result.
If you could provide a minimal repro or the code that leads to this it would help a great deal.

1 Like

Edgy case