FuelLabs / fuels-ts

Fuel Network Typescript SDK
https://docs.fuel.network/docs/fuels-ts/
Apache License 2.0
44.26k stars 1.34k forks source link

`txSummary` not returning contract call operation in some cases #2448

Closed LuizAsFight closed 2 months ago

LuizAsFight commented 3 months ago

What version of fuels-ts are you using?

0.88.1

Steps to Reproduce

More details

The screen above tries to show the operations of the transaction for the user to check and confirm it. It's currently showing no operations.

Behind the scenes it's consuming getTransactionSummary. When this method tries to compute the contract call operations, it tries to identify who called the contract using the assetId returned from the receipt.

The problem is that the receipt returns 0x0000..., as there was no assetId in the contract call made. The previous code was working only because the baseAssetId was the same, and the input would have the correct assetId.

Solution

When the receipt returns assetId: 0x0000..., consider getting the input that has the current baseAssetId, meaning that who payed the fee will be identified as the contract caller.

fuel-core https://github.com/FuelLabs/fuel-core/issues/1941

I think this is something that could be changed in the VM, it could return null instead of 0x0000..., but it doesn't change the solution above

maschad commented 3 months ago

I think the more permanent fix for this should involve fuel-core determining what the correct response is based on https://github.com/FuelLabs/fuel-core/issues/1941

In the interim we have released a patch which solves this.

LuizAsFight commented 2 months ago

@maschad makes sense to close this issue? the bug in this issue is fixed.

the change on VM may or may not happen haha, can it be tracked in another issue as an improvement instead of a bug ?

cc @arboleya

maschad commented 2 months ago

I agree @LuizAsFight this particular issue closed since both

have been created to address this on our end going forward, if https://github.com/FuelLabs/fuel-core/issues/1941 gets integrated on fuel-core then we can create another issue to make accommodations for that.