tools: fix lagging cinfo.AppParams data structure in PingPong #4613
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4613 +/- ##
==========================================
+ Coverage 54.20% 54.25% +0.04%
==========================================
Files 402 402
Lines 51830 51849 +19
==========================================
+ Hits 28096 28130 +34
+ Misses 21370 21358 -12
+ Partials 2364 2361 -3
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
algoidurovic
changed the title
shared/pingpong/accounts.go
Outdated
| pps.schedule(len(txgroup)) | ||
| err = pps.sendAsGroup(txgroup, client, senders) | ||
| appsPerAddr := make(map[string]int) | ||
| totalAppCnt := 0 |
There was a problem hiding this comment.
This loses the possibility that accounts with apps already exist. One of the big changes in my recent pingpong hacking was that we can now have stable accounts and apps and assets that exist over multiple invocations of pingpong. Maybe existingAppCnt := len(pps.cinfo.AppParams) and then loop while newAppCnt + existingAppCnt < pps.cfg.NumApp
There was a problem hiding this comment.
Ah got it. That explains a few things I was confused about, like why some failing pingpong invocations worked on subsequent runs. Your suggestion makes sense.
3 participants
Summary
This PR intends to fix the following issues in PingPong's
pps.prepareApps():pps.cinfo.AppParamsis used in multiples places (ex. terminating from the app creation loop and appID access in the opt in loop) where its contents lag behind what the code expects. The solution is to either block until there are no longer apps pending creation and then updateAppParamsor remove the reference toAppParamsentirely.Test Plan
Tested on local Algorand network.