-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added RelayedV3 method in RelayedTransactionsFactory #460
Conversation
@@ -28,6 +28,10 @@ export class TransactionsConverter { | |||
guardian: transaction.guardian ? transaction.guardian : undefined, | |||
signature: this.toHexOrUndefined(transaction.signature), | |||
guardianSignature: this.toHexOrUndefined(transaction.guardianSignature), | |||
relayer: transaction.relayer ? transaction.relayer : undefined, | |||
innerTransactions: transaction.innerTransactions.length |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it an option to have innerTransactions
as an empty array if there's no item?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, below, and in other places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Later comment: actually, it's good that toPlainObject()
returns undefined if these new fields are missing 👍
Otherwise, downstream, some errors might have occurred. E.g. sending toPlainObject()
to a gateway etc. (while these new fields - even if empty - aren't supported yet).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure, here maybe it could work but in other places we check the length and make it undefined anyway if there's no inner transaction(e.g. serializing for signing). Is there a reason why we'd make it an empty array instead of undefined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's good as it is (see the later comment) 👍
Generally speaking, reason for empty array instead of undefined: leads to less errors in client code (e.g. better to iterate over empty arrays, than pre-checking if an array is defined, then iterate over it).
But in this context, it's good.
@@ -139,6 +152,9 @@ export class Transaction { | |||
|
|||
this.signature = options.signature || Buffer.from([]); | |||
this.guardianSignature = options.guardianSignature || Buffer.from([]); | |||
|
|||
this.relayer = options.relayer || ""; | |||
this.innerTransactions = options.innerTransactions || []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
chainID: this.config.chainID, | ||
gasLimit: gasLimit, | ||
innerTransactions: options.innerTransactions, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, so the relayer
field does not have to be set, it seems?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the relayer
field is only set for the inner transactions
relayer?: string; | ||
innerTransactions?: IPlainTransactionObject[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, optional, to have this as a non-breaking change.
@@ -104,4 +106,6 @@ export interface ITransaction { | |||
guardian: string; | |||
signature: Uint8Array; | |||
guardianSignature: Uint8Array; | |||
relayer: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Breaking change? Can we handle this differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, theoretically it is a breaking change, but i assume everybody uses our Transaction
class so it shouldn't be a big deal. Did we make a major release when guardians were added as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For guardians, indeed, we did (though it wasn't the sole reason): https://github.com/multiversx/mx-sdk-js-core/releases/tag/v12.0.1.
For practicality, yes, makes sense to treat it as a not-really-breaking-change, agree 👍
Scenario for breaking change (hypothetically speaking): some client code references and uses the interface - even we are thinking of it as an internal interface.
Now I see, in sdk-core it's only used in TransactionWatcher
. Then, maybe, even have the Transaction
class use the concrete Transaction
DTO as inner transactions
?
src/transactionComputer.ts
Outdated
}; | ||
} | ||
|
||
private toPlainObject(transaction: ITransaction): any { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach is different from the one in PY.
Can also stay as it is, can also be refactored for symmetry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refactored it for symmetry. Also renamed the method.
serializedTransaction.toString("hex"), | ||
"08cc011209000de0b6b3a76400001a200139472eff6886771a982f3083da5d421f24c29181e63888228dc81ca60d69e12205616c6963652a20b2a11555ce521e4944e09ab17549d85b487dcd26c84b5017a39e31a3670889ba32056361726f6c388094ebdc0340d0860352015458026240901a6a974d6ab36546e7881c6e0364ec4c61a891aa70e5eb60f818d6c92a39cfa0beac6fab73f503853cfe8fe6149b4be207ddb93788f8450d75a07fa8759d06820120b2a11555ce521e4944e09ab17549d85b487dcd26c84b5017a39e31a3670889ba8a01b10108cc011209000de0b6b3a76400001a200139472eff6886771a982f3083da5d421f24c29181e63888228dc81ca60d69e12205616c6963652a20b2a11555ce521e4944e09ab17549d85b487dcd26c84b5017a39e31a3670889ba32056361726f6c388094ebdc0340d086035201545802624051e6cd78fb3ab4b53ff7ad6864df27cb4a56d70603332869d47a5cf6ea977c30e696103e41e8dddf2582996ad335229fdf4acb726564dbc1a0bc9e705b511f06", | ||
); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I see that we have nonce = 204
for both the inner and the relayed transaction. Also same sender & receiver in inner vs. relayed. In PY as well.
Might lead to some ambiguity for some readers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we change this? In JS & PY?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it like this to match the test in sdk-py. We could leave it like this for the moment and replace it in the near future with some more explicit tests.
src/proto/serializer.ts
Outdated
import { bigIntToBuffer } from "../smartcontracts/codec/utils"; | ||
import { Transaction } from "../transaction"; | ||
|
||
const proto = require("./compiled").proto; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was problematic in the past.
Can we undo for the moment, then think of a better solution in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, done!
|
||
let protoTransaction = new proto.Transaction({ | ||
// mx-chain-go's serializer handles nonce == 0 differently, thus we treat 0 as "undefined". | ||
Nonce: transaction.getNonce().valueOf() ? transaction.getNonce().valueOf() : undefined, | ||
Value: this.serializeTransactionValue(transaction.getValue()), | ||
Nonce: Number(transaction.nonce) ? Number(transaction.nonce) : undefined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed.
sender: bob.address.toBech32(), | ||
receiver: bob.address.toBech32(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could have been alice to bob.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did it to match the test in sdk-py
No description provided.