test(kuma-cp): fix wait for goroutine to be done

[lukidzi]

There was some race after adding another test. Added lock for counter increment and made one test wait for the goroutine to be done before finishing the test.

• Link to docs PR or issue --
• Link to UI issue or PR --
• Is the issue worked on linked? --
• The PR does not hardcode values that might break projects that depend on kuma (e.g. "kumahq" as a image registry) --
• The PR will work for both Linux and Windows, system specific functions like syscall.Mkfifo have equivalent implementation on the other OS --
• Unit Tests --
• E2E Tests --
• Manual Universal Tests --
• Manual Kubernetes Tests --
• Do you need to update UPGRADE.md? --
• Does it need to be backported according to the backporting policy? --
• Do you need to explicitly set a > Changelog: entry here or add a ci/ label to run fewer/more tests?

Changelog skip

[lukidzi]

@Mergifyio backport release-2.0 release-1.8 release-1.7 release-1.6 release-1.5

[mergify]

backport release-2.0 release-1.8 release-1.7 release-1.6 release-1.5

✅ Backports have been created

• #5644 test(kuma-cp): fix wait for goroutine to be done (backport #5638) has been created for branch release-2.0
• #5645 test(kuma-cp): fix wait for goroutine to be done (backport #5638) has been created for branch release-1.8
• #5646 test(kuma-cp): fix wait for goroutine to be done (backport #5638) has been created for branch release-1.7
• #5647 test(kuma-cp): fix wait for goroutine to be done (backport #5638) has been created for branch release-1.6
• #5648 test(kuma-cp): fix wait for goroutine to be done (backport #5638) has been created for branch release-1.5

[lahabana]

Would it be easier to use sync.atomic ?

Also seems like this problem also exists with getQueries

[jakubdyszkiewicz]

Please use > Changelog skip. This may confuse users that it is a fix to the production code where in fact this is fix for the test. The alternative is to name it test: fix wait for goroutine...

[lobkovilya]

Are you sure it fixes the problem? According to the output here it doesn't like accessing the cachedManager variable from 2 different goroutines.

[lukidzi]

Are you sure it fixes the problem? According to the output here it doesn't like accessing the cachedManager variable from 2 different goroutines.

It seems that is fixed. One of the issues was that slow action was hanging in other goroutine and waiting. Now before running the next test we wait for that goroutine to close before. I've tested by running

for i in {1..100}; do go clean -testcache && make test TEST_PKG_LIST=./pkg/core/resources/manager/... ; done

and had no error.

[lahabana]

@lukidzi will you need to backport this too?