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

test: initial subxt test #990

Merged
merged 7 commits into from
Jun 21, 2023
Merged

test: initial subxt test #990

merged 7 commits into from
Jun 21, 2023

Conversation

extraymond
Copy link
Contributor

alternative tests using subxt, currently using raw selector until the ABI are compatible where we can just use contract-transcode.
test cases are semantically derived from the original substrate integration tests using polkadot.js.

@extraymond
Copy link
Contributor Author

extraymond commented Aug 30, 2022

Started to use contract-transcode for encoding message selector, which works with the two exception:

  1. when using constructor overloading, due to all constructors have the same name, which contract-transcode will only match the first one, currently it'll never reach the second constructor.
  2. transcoding U256/I256 won't work. U256 is configured with sp_core::U256 as it's custom transcoder but it won't actually use it since it's using the TypeInfo::type_info() to get the Path, which is all empty for solang runtime types. I256 is unprocessed at all.

@xermicus
Copy link
Contributor

I think this is a great effort overall!

when using constructor overloading, due to all constructors have the same name, which contract-transcode will only match the first one, currently it'll never reach the second constructor.

Options I see so far:

  • Introduce a custom attribute to set a name for the constructor (e.g. like the way it is done for selector), and default to new or something else when no overloading is happening and no name is given.
  • Mangle the name based by its arguments, would be less work to code up I guess, but ugly from a user perspective

transcoding U256/I256 won't work. U256 is configured with sp_core::U256 as it's custom transcoder but it won't actually use it since it's using the TypeInfo::type_info() to get the Path, which is all empty for solang runtime types. I256 is unprocessed at all.

U256 is not (yet) supported in ink!. The easiest solution would be if we can get it to work by using the U256 path of ethereum-types lib somehow?

@extraymond extraymond force-pushed the subxt-tests branch 2 times, most recently from 4c58a90 to 9e9a8d8 Compare September 5, 2022 10:21
Copy link
Contributor

@seanyoung seanyoung left a comment

Choose a reason for hiding this comment

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

First review comments, looks good so far

.github/workflows/test.yml Outdated Show resolved Hide resolved
.github/workflows/test.yml Outdated Show resolved Hide resolved
.github/workflows/test.yml Outdated Show resolved Hide resolved
.gitignore Outdated Show resolved Hide resolved
integration/subxt-tests/Cargo.toml Outdated Show resolved Hide resolved
integration/subxt-tests/src/cases/structs.rs Outdated Show resolved Hide resolved
@xermicus
Copy link
Contributor

xermicus commented Nov 21, 2022

@extraymond it makes me sad that we didn't go forward sooner with this PR, sorry! I really like what you implemented here. In the long run, it would make sense to integrate this with #1061. How-ever, this should not block your nice work here. May I ask you for the favor of merging current main with this again? Then I'd be very happy to give a usual round of review and LGTM!

@extraymond
Copy link
Contributor Author

@extraymond it makes me sad that we didn't go forward sooner with this PR, sorry! I really like what you implemented here. In the long run, it would make sense to integrate this with #1061. How-ever, this should not block your nice work here. May I ask you for the favor of merging current main with this again? Then I'd be very happy to give a usual round of review and LGTM!

Sure! I'll be on it sometime this week.

@xermicus
Copy link
Contributor

xermicus commented Nov 23, 2022

Sure! I'll be on it sometime this week.

Awesome, thanks! While you're on it, can you directly aim for compatibility with pallets contract v0.22.1 (it uses WeightV2)? Not all contracts will work ATM though, as I have to fix some imports first (gonna make a PR for this).

EDIT: #1080

Signed-off-by: Raymond Yeh <extraymond@gmail.com>
@extraymond
Copy link
Contributor Author

@xermicus @seanyoung
Rebased to current master. Some failed tests are ignored as suggested. Looking forward for your review.

@extraymond extraymond changed the title WIP: test: initial subxt test test: initial subxt test Jun 18, 2023
Signed-off-by: Raymond Yeh <extraymond@gmail.com>
Signed-off-by: Raymond Yeh <extraymond@gmail.com>
@xermicus
Copy link
Contributor

@extraymond FYI the rust source files need a SPDX header, this is why the Lints job failed (unfortunately it'll just time out if there are some headers missing)

@extraymond
Copy link
Contributor Author

Ah! Got it.

@extraymond FYI the rust source files need a SPDX header, this is why the Lints job failed (unfortunately it'll just time out if there are some headers missing)

Ah got it, I'll fix it later.

Copy link
Contributor

@xermicus xermicus left a comment

Choose a reason for hiding this comment

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

Gave it a first round of review; looks great overall, I hope to merge this soon. Thank you so much for keeping this going! ❤️

.github/workflows/test.yml Outdated Show resolved Hide resolved
.github/workflows/test.yml Outdated Show resolved Hide resolved
integration/subxt-tests/src/lib.rs Outdated Show resolved Hide resolved
integration/subxt-tests/src/lib.rs Outdated Show resolved Hide resolved
integration/subxt-tests/src/lib.rs Outdated Show resolved Hide resolved
.github/workflows/test.yml Show resolved Hide resolved
integration/subxt-tests/src/cases/arrays.rs Outdated Show resolved Hide resolved
integration/subxt-tests/src/cases/events.rs Show resolved Hide resolved
integration/subxt-tests/src/cases/external_call.rs Outdated Show resolved Hide resolved
Signed-off-by: Raymond Yeh <extraymond@gmail.com>
Signed-off-by: Raymond Yeh <extraymond@gmail.com>
@extraymond
Copy link
Contributor Author

@xermicus I think it would be nice to tap into debug buffer when contract trapped. It's very hard to debug why it's trapped within the test.

@xermicus
Copy link
Contributor

@xermicus I think it would be nice to tap into debug buffer when contract trapped. It's very hard to debug why it's trapped within the test.

I see what you mean; however I think this should ideally be done by contracts pallet (so the runtime executing the contract). In the contract code itself, we have limited control about trapping. We might write into the debug buffer if we know for sure we are going to trap (for example because the compiler inserts a trap manually). However, there are many other cases (OOM, invalid instructions etc) only the runtime knows or has control about.

For this to work we would need to provide the runtime debug info, but for now IIRC the contracts pallet doesn't support this.

@extraymond
Copy link
Contributor Author

@xermicus I think it would be nice to tap into debug buffer when contract trapped. It's very hard to debug why it's trapped within the test.

I see what you mean; however I think this should ideally be done by contracts pallet (so the runtime executing the contract). In the contract code itself, we have limited control about trapping. We might write into the debug buffer if we know for sure we are going to trap (for example because the compiler inserts a trap manually). However, there are many other cases (OOM, invalid instructions etc) only the runtime knows or has control about.

For this to work we would need to provide the runtime debug info, but for now IIRC the contracts pallet doesn't support this.

Yeah, cargo-contract does it by doing a sequential read call if a first write call failed. Maybe we should revisit it later when we have some shared lib from cargo-contract that we can directly pulled.

@xermicus xermicus marked this pull request as ready for review June 19, 2023 12:42
@xermicus xermicus requested a review from LucasSte as a code owner June 19, 2023 12:42
@xermicus xermicus requested a review from seanyoung June 19, 2023 12:42
Copy link
Contributor

@LucasSte LucasSte left a comment

Choose a reason for hiding this comment

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

LGTM

integration/subxt-tests/src/cases/primitives.rs Outdated Show resolved Hide resolved
Signed-off-by: Raymond Yeh <extraymond@gmail.com>
@extraymond
Copy link
Contributor Author

@seanyoung I think one of my forced push for rebase cleared your original change request. I believe I have implemented the suggestion back then.

Copy link
Contributor

@xermicus xermicus left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@seanyoung seanyoung left a comment

Choose a reason for hiding this comment

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

Looks great. I only skimmed the new tests - a huge amount, great stuff!

.github/workflows/test.yml Outdated Show resolved Hide resolved
.github/workflows/test.yml Outdated Show resolved Hide resolved
BREAKING CHANGE:

Signed-off-by: Raymond Yeh <extraymond@gmail.com>
@xermicus
Copy link
Contributor

Amazing, thank you!

@xermicus xermicus merged commit 0170778 into hyperledger:main Jun 21, 2023
16 of 17 checks passed
@seanyoung
Copy link
Contributor

@extraymond good stuff, thanks!

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.

4 participants