CallReceipt is returning wrong from property

[LuizAsFight]

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

• ReceiptCall
  *

[petertonysmith94]

Summary

• I agree with this assessment that the from property should be changed to id.
• It seems like the from property isn't even returned - I do question if the spec's are also off?
• I also looked over the Transfer and TransferOut and they also have a similar issue (from what I understand).

Call

• from in spec
• from in ts
• id in fuel-core

Transfer

• from in spec
• from in ts
• id in fuel-core

TransferOut

• from in spec
• from in ts
• id in fuel-core

[petertonysmith94]

@danielbate you mentioned in sync about other possible mismatches?

[danielbate]

I believe #2530 and #2448 are related.

[Torres-ssf]

@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]

@Torres-ssf Can this be closed?

[Torres-ssf]

@arboleya I am not enterely sure.

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

[arboleya]

@LuizAsFight Gentle ping — any input here?

[LuizAsFight]

@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]

@LuizAsFight I am closing this as it was addressed on FuelLabs/fuel-specs#610

[petertonysmith94]

@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).

[Torres-ssf]

@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