Skip to content
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

Merged
merged 4 commits into from
Jun 11, 2024
Merged

Conversation

popenta
Copy link
Contributor

@popenta popenta commented Jun 10, 2024

No description provided.

@popenta popenta self-assigned this Jun 10, 2024
@andreibancioiu andreibancioiu self-requested a review June 10, 2024 08:38
@@ -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
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

@andreibancioiu andreibancioiu Jun 11, 2024

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

Copy link
Contributor Author

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?

Copy link
Contributor

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 || [];
Copy link
Contributor

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,
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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

Comment on lines +27 to +28
relayer?: string;
innerTransactions?: IPlainTransactionObject[];
Copy link
Contributor

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;
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

@andreibancioiu andreibancioiu Jun 11, 2024

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?

};
}

private toPlainObject(transaction: ITransaction): any {
Copy link
Contributor

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.

https://github.com/multiversx/mx-sdk-py/blob/feat/next/multiversx_sdk/core/transaction_computer.py#L94

Can also stay as it is, can also be refactored for symmetry.

Copy link
Contributor Author

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",
);
});
Copy link
Contributor

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.

https://github.com/multiversx/mx-sdk-py/blob/feat/next/multiversx_sdk/core/proto/transaction_serializer_test.py

Might lead to some ambiguity for some readers.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

import { bigIntToBuffer } from "../smartcontracts/codec/utils";
import { Transaction } from "../transaction";

const proto = require("./compiled").proto;
Copy link
Contributor

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.

#295

Can we undo for the moment, then think of a better solution in a separate PR?

Copy link
Contributor Author

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed.

Comment on lines +281 to +282
sender: bob.address.toBech32(),
receiver: bob.address.toBech32(),
Copy link
Contributor

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.

Copy link
Contributor Author

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

@popenta popenta merged commit 152b90a into feat/next Jun 11, 2024
1 check passed
@popenta popenta deleted the relayed-v3 branch June 11, 2024 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants