Reusing the object reference passed into utils.eventuallyObject() creates a race condition inside the client, resulting in stale or incomplete data being compared in the matcher.
This PR aims to fix this by creating a fresh struct each time and using a non-caching client.Client in all tests.
Also included: update controller-runtime to 0.2.2 for good measure as well as reverting all Eventually() timeouts to the original 5s.
EDIT:
After more debugging it turns out that something about testenv or the way we're using it is inherently not thread-safe.
Tests are reliable only when running them without -p.
I have confirmed that this problem is confined to testenv and not the code under test.
Thus, for now and going forward tests will run without -p.
Reusing the object reference passed into
utils.eventuallyObject()
creates a race condition inside the client, resulting in stale or incomplete data being compared in the matcher.This PR aims to fix this by creating a fresh struct each time and using a non-caching
client.Client
in all tests.Also included: update controller-runtime to 0.2.2 for good measure as well as reverting all
Eventually()
timeouts to the original 5s.EDIT: After more debugging it turns out that something about testenv or the way we're using it is inherently not thread-safe. Tests are reliable only when running them without
-p
. I have confirmed that this problem is confined to testenv and not the code under test. Thus, for now and going forward tests will run without-p
.