-
Notifications
You must be signed in to change notification settings - Fork 725
test: delayed receipts example #14481
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
Conversation
0d7399e to
5ababd0
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #14481 +/- ##
===========================================
+ Coverage 16.85% 70.75% +53.89%
===========================================
Files 895 895
Lines 194314 194411 +97
Branches 194314 194411 +97
===========================================
+ Hits 32757 137553 +104796
+ Misses 159652 50843 -108809
- Partials 1905 6015 +4110
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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 a big fan of examining trie - see related comment.
If there's no way around it - lgtm.
| let trie = rpc_node.trie( | ||
| env.test_loop_data(), | ||
| rpc_node.head(env.test_loop_data()).last_block_hash, | ||
| ShardId::new(0), | ||
| ); | ||
| let delayed_receipt_indices: DelayedReceiptIndices = | ||
| near_store::get(&trie, &TrieKey::DelayedReceiptIndices).unwrap().unwrap(); | ||
| assert_eq!( | ||
| delayed_receipt_indices, | ||
| DelayedReceiptIndices { first_index: 0, next_available_index: 1 } | ||
| ); | ||
| let delayed_receipt: StateStoredReceipt = near_store::get( | ||
| &trie, | ||
| &TrieKey::DelayedReceipt { index: delayed_receipt_indices.first_index }, | ||
| ) | ||
| .unwrap() | ||
| .unwrap(); |
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.
Not sure if this is actionable or makes sense, but e2e tests are generally meant to test things from a user's point of view. In our case I think it's fair to assume that user is able to observe the chain, but I am not sure if it's fair to assume they can access the trie directly. Would it be possible to use some API to get required information here or maybe check that last tx finishes execution one block later? (Especially for an example: depending on internals of the trie feels a lot like depending on implementation details, which might make tests brittle generally.)
As an example this might break with spice or become flaky since last block may not have chunk extra.
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 is a very good point, thanks! updated in be36b5d
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.
lgtm, thanks
| SignedTransaction::call( | ||
| next_nonce(), | ||
| user_account.clone(), | ||
| user_account.clone(), | ||
| &create_user_test_signer(&user_account), | ||
| Balance::ZERO, | ||
| "burn_gas_raw".to_owned(), | ||
| gas_to_burn.as_gas().to_le_bytes().to_vec(), | ||
| gas_limit, | ||
| rpc_node.head(env.test_loop_data()).last_block_hash, | ||
| ) |
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.
As an idea not related to this PR it might make sense to make it easier to create txs with rpc nodes (since likely rpc nodes are the ones usually used for sending txs). In that api deriving user signer, nonce and latest block hash can be automatic.
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.
yep, 100% agree, I plan adding that to test loop tooling soon
820f77d to
55f52ef
Compare
80e5015 to
be36b5d
Compare
|
@attila0x2A I've updated assertion logic to avoid looking into trie, could you please take another look 🙏 |
| pub fn block(&self, test_loop_data: &TestLoopData, block_hash: CryptoHash) -> Arc<Block> { | ||
| self.client(test_loop_data).chain.get_block(&block_hash).unwrap() | ||
| } |
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.
Also not related to this PR, but it would be very good to modify existing code that doesn't use all the new helpers to use them. Maybe a good use-case for ai.
With inconsistency as is it's hard to make sure that all the new tests would use the new helpers.
No description provided.