testing: fix bug in TestAssetGroupCreateSendDestroy

[tsachiherman]

Summary

Fix a bug in TestAssetGroupCreateSendDestroy. The test uses two nodes, sending transaction to one and checking the state on the other. Before checking, the test need to verify that both nodes successfully reached the same round number.

Test Plan

This is a test.

[codecov-commenter]

Codecov Report

Merging #3631 (2e2f638) into master (73ff45d) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3631      +/-   ##
==========================================
- Coverage   48.06%   48.04%   -0.03%     
==========================================
  Files         381      381              
  Lines       62080    62080              
==========================================
- Hits        29838    29825      -13     
- Misses      28822    28828       +6     
- Partials     3420     3427       +7     

Impacted Files	Coverage Δ
cmd/algoh/blockWatcher.go	77.77% <0.00%> (-3.18%)	⬇️
ledger/tracker.go	74.45% <0.00%> (-1.30%)	⬇️
ledger/acctupdates.go	65.46% <0.00%> (-0.95%)	⬇️
data/abi/abi_type.go	87.67% <0.00%> (-0.95%)	⬇️
data/transactions/verify/txn.go	44.15% <0.00%> (-0.87%)	⬇️
network/wsNetwork.go	62.79% <0.00%> (-0.20%)	⬇️
catchup/service.go	69.38% <0.00%> (ø)
network/wsPeer.go	68.33% <0.00%> (+0.27%)	⬆️
network/requestTracker.go	71.12% <0.00%> (+0.86%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73ff45d...2e2f638. Read the comment docs.

[algonautshant]

Looks great.
Just one comment to confirm my understanding.

[algonautshant]

So, I understand that the idea here is that both nodes agree on the block with all the transactions, client0 adds the block in its ledger, returns confirmed on line 638.

However, it could be possible that client1 has not yet added the block and advanced the round, and the client1.AssetInformation(assetID1) fails.

So, by client1.WaitForRound(status0.LastRound) you are making sure that client1 has also added the block before calling client1.AssetInformation(assetID1).

Is this right?

[tsachiherman]

Exactly

…

On Mon, Feb 14, 2022, 23:00 Shant Karakashian ***@***.***> wrote: ***@***.**** approved this pull request. Looks great. Just one comment to confirm my understanding. ------------------------------ In test/e2e-go/features/transactions/asset_test.go <#3631 (comment)>: > a.True(confirmed) + status0, err = client0.Status() + a.NoError(err) + + // wait for client1 to reach the same round as client0 + _, err = client1.WaitForRound(status0.LastRound) So, I understand that the idea here is that both nodes agree on the block with all the transactions, client0 adds the block in its ledger, returns confirmed on line 638. However, it could be possible that client1 has not yet added the block and advanced the round, and the client1.AssetInformation(assetID1) fails. So, by client1.WaitForRound(status0.LastRound) you are making sure that client1 has also added the block before calling client1.AssetInformation(assetID1). Is this right? — Reply to this email directly, view it on GitHub <#3631 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF2OOH7MGONRXEFWVAOYIT3U3HFUVANCNFSM5ONF47HQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were assigned.Message ID: ***@***.***>