search

FuelLabs / fuels-ts

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

CallReceipt is returning wrong `from` property #2449

Open LuizAsFight opened 4 months ago

LuizAsFight commented 4 months ago

Motivation

Contract Call receipts are getting a from property I think from is not correct for this receipt. It should be id like in other case inside that same switch, or it should be removed.

reasons according to spec : 1- shows Call contracts prop already have a from prop 2- there is no contractId and no id in CallReceipt, which means the from being provided by this method will be always 0x0000...

UPDATE

To fix this, we need to ensure that the TS SDK's receipts types are in alignment with the Fuel specs

Spec changes

petertonysmith94 commented 4 months ago

Summary

Call

Transfer

TransferOut

petertonysmith94 commented 4 months ago

@danielbate you mentioned in sync about other possible mismatches?

danielbate commented 4 months ago

I believe #2530 and #2448 are related.

Torres-ssf commented 3 months ago

@LuizAsFight there is no error here.

We cannot rename from to id on the CallReceipt type as on the specs for this receipt the property name is from and not id.

Also, the property from does not exist within the raw receipt type returned by fuel-core.

That is why its value is being extracted from id.

The value for from will be null/undefined most of the time. Just like it is said within the specs:

from: Hexadecimal string representation of the 256-bit (32-byte) contract ID of the current context if in an internal context; null otherwise.

This property will only be defined in case of a contract that is calling another contract. When this is not the case, it will be null. That is why in most cases its value is 0x0000...

arboleya commented 2 months ago

@Torres-ssf Can this be closed?

Torres-ssf commented 2 months ago

@arboleya I am not enterely sure.

I may have misunderstood @LuizAsFight statement, so I am waiting for his confirmation

arboleya commented 1 month ago

@luizasfight Gentle ping — any input here?

LuizAsFight commented 1 month ago

@arboleya @Torres-ssf

the problem here is returning things different from spec.

for instace this is what the spec says about "from" field in Call receipts:

from: Hexadecimal string representation of the 256-bit (32-byte) contract ID of the current context if in an internal context; null otherwise.

and this is what the sdk returns from "from" field

from: hexOrZero(receipt.id || receipt.contractId),

problem 1: "from" returned by sdk doesn't reflect the real "from" from spec problem 2: "from" is not returned anywhere inside of callReceipt, so users don't have access to it problem 3: "contractId" doesn't exist on spec for Call receipt problem 4: "id" doesn't exist on spec for Call receipt problem 5: the union of problem 3 and 4, makes the field "from" be returned always as zero (0x) in current implementation

Instead of returning the above I believe the sdk should return it parsed but don't manipulate the fields, something like:

from: hexOrZero(receipt.from),

I think all receipt types should be visited to check if this happens also, and then fix them

Torres-ssf commented 1 month ago

@LuizAsFight I am closing this as it was addressed on https://github.com/FuelLabs/fuel-specs/pull/610

petertonysmith94 commented 1 month ago

@torres-ssf should we be closing this one? I'd of thought we'd need to sync with the specification?

For my understanding of the spec PR, it now appears that we're not aligned with the specification:

Torres-ssf commented 2 weeks ago

@Torres-ssf should we be closing this one? I'd of thought we'd need to sync with the specification?For my understanding of the spec PR, it now appears that we're not aligned with the specification:

  • e.g. ReceiptCall in the spec has changed from from to id , and we still maintain this as from (here).

@petertonysmith94 You are correct