Receipt::Panic's contract_id
isn't serialized, resulting in it not being provided by the GraphQL server
#1009
Labels
question
Further information is requested
This may be better suited for https://github.com/FuelLabs/fuel-vm (as things are written, the root cause lives there), but this mostly relates to fuel-core functionality so figured I'd open here.
I also see by poking through some PRs/issues related to the panic contract_id (FuelLabs/fuel-vm#261, FuelLabs/fuel-vm#256, etc) that the issue I'll describe may be intentional / already known
I initially noticed that the
contract_id
of aPanic
receipt was always set toNone
when I was hitting aContractNotInInputs
error in some harness tests where I was using fuels-rs. I had previously browsed the vm code and knew that the contract ID should be present to help debug, so I poked around a bit. Adding some logs confirmed that the VM / core logic was accurately setting the Receipt::Panic's contract_id when the tx was executed, but it was getting lost somewhere along the way before fuels-rs was surfacing a responseWhen
fuel-core
's GraphQL server serializes receipts, it does so by using theraw_payload
function which uses theio::Read
impl to serialize to aHexString
. Theio::Read
implementation doesn't set thecontract_id
, sofuel-core
ends up always responding to GraphQL requests with Receipt::Panic raw payloads that don't include the contract id. Then when a GraphQL client tries to deserialize OpaqueReceipts, I believe it'll then use the Receiptio::Write
implementation, which similarly doesn't attempt to set the contract_id for a panic receiptI've confirmed this is the root cause by naively locally changing the
io::Read
/io::Write
impls to read/write the contract_id & changed the SizedBytes impl, but I have a feeling this may have unintended consequences so wanted to open this before suggesting/attempting a specific fixThe text was updated successfully, but these errors were encountered: