Skip to content

Flaky test fixes #580

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.

Sign up for GitHub

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

Open
lucian-tosa wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Flaky test fixes #580

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2000bcf
Add persist_for in phase assertions
lucian-tosa Nov 10, 2025
b3201cf
Increase timeouts
lucian-tosa Nov 10, 2025
4c1dd1b
Precommit
lucian-tosa Nov 10, 2025
75e91ff
Split persisting in its own method
lucian-tosa Dec 11, 2025
25ce1e7
Merge branch 'master' into lucian/flaky-test-fixes
lucian-tosa Dec 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions docker/mongodb-kubernetes-tests/kubetester/mongodb_common.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,20 +11,26 @@

class MongoDBCommon:
@TRACER.start_as_current_span("wait_for")
def wait_for(self, fn, timeout=None, should_raise=True):
def wait_for(self, fn, timeout=None, should_raise=True, persist_for=1):
Copy link
Contributor

@lsierant lsierant Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is persist_for essentially equivalent to "required consecutive successes to pass"?

Copy link
Contributor

@lsierant lsierant Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if yes, then pls leave a brief comment or rename it, it took me a bit thinking to get the meaning of this param

Copy link
Contributor

@lsierant lsierant Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and one of the reason was that when looking for "persist for" suggest that the "problem persists" or the goal is not achieve yet and the situation persists. When something succeeds it's not often described as a situation that "persists". But I might be nitpicking here.

Copy link
Contributor Author

@lucian-tosa lucian-tosa Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is persist_for essentially equivalent to "required consecutive successes to pass"?

Yes

Not the best name, I know, I couldn't find a better one. I can add a comment. But do you have a better option? no_of_successful_passes?

Copy link
Contributor

@m1kola m1kola Nov 19, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I'm not a fan of Gomega and Ginkgo I think we should separate "wait for something" from "consistently passes meets something" like they do:

Copy link
Contributor Author

@lucian-tosa lucian-tosa Dec 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed, I created a new method assert_persist_phase, and opened a ticket to track the root issue
please take another look

Copy link
Collaborator

@Julien-Ben Julien-Ben Dec 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks ! I like that we have the two high level methods assert_reaches_phase and assert_persist_phase separated now.

Copy link
Contributor

@m1kola m1kola Dec 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also like how we now have assert_reaches_phase and assert_persist_phase, but still find wait_for to be a bit confusing. It's difficult to get what it does just by looking at the signature.

I'm not going to block on this, but if you can think of a way so we can leave wait_for as it was before and introduce another low level function with a simple signature - that would be awesome.

if timeout is None:
timeout = 600
initial_timeout = timeout

wait = 3
retries = 0
while timeout > 0:
try:
self.reload()
except Exception as e:
print(f"Caught error: {e} while waiting for {fn.__name__}")
pass
if fn(self):
return True
retries += 1
if retries == persist_for:
return True
else:
retries = 0

timeout -= wait
time.sleep(wait)

Expand Down
49 changes: 42 additions & 7 deletions docker/mongodb-kubernetes-tests/kubetester/opsmanager.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1017,13 +1017,7 @@ def is_om_multi_cluster(self):
return self["spec"].get("topology", "") == "MultiCluster"

class StatusCommon:
def assert_reaches_phase(
self,
phase: Phase,
msg_regexp=None,
timeout=None,
ignore_errors=False,
):
def assert_reaches_phase(self, phase: Phase, msg_regexp=None, timeout=None, ignore_errors=False):
intermediate_events = (
# This can be an intermediate error, right before we check for this secret we create it.
# The cluster might just be slow
Expand Down Expand Up @@ -1057,6 +1051,41 @@ def assert_reaches_phase(
f"Reaching phase {phase.name} for resource {self.__class__.__name__} took {end_time - start_time}s"
)

def assert_persist_phase(self, phase: Phase, msg_regexp=None, timeout=None, ignore_errors=False, persist_for=3):
intermediate_events = (
# This can be an intermediate error, right before we check for this secret we create it.
# The cluster might just be slow
"failed to locate the api key secret",
# etcd might be slow
"etcdserver: request timed out",
)

start_time = time.time()
self.ops_manager.wait_for(
lambda s: in_desired_state(
current_state=self.get_phase(),
desired_state=phase,
current_generation=self.ops_manager.get_generation(),
observed_generation=self.get_observed_generation(),
current_message=self.get_message(),
msg_regexp=msg_regexp,
ignore_errors=ignore_errors,
intermediate_events=intermediate_events,
),
timeout,
should_raise=True,
persist_for=persist_for,
)
end_time = time.time()
span = trace.get_current_span()
span.set_attribute("mck.resource", self.__class__.__name__)
span.set_attribute("mck.action", "assert_phase")
span.set_attribute("mck.desired_phase", phase.name)
span.set_attribute("mck.time_needed", end_time - start_time)
logger.debug(
f"Persist phase {phase.name} ({persist_for} retries) for resource {self.__class__.__name__} took {end_time - start_time}s"
)

def assert_abandons_phase(self, phase: Phase, timeout=None):
return self.ops_manager.wait_for(lambda s: self.get_phase() != phase, timeout, should_raise=True)

Expand Down Expand Up @@ -1113,6 +1142,9 @@ def assert_abandons_phase(self, phase: Phase, timeout=400):
def assert_reaches_phase(self, phase: Phase, msg_regexp=None, timeout=1000, ignore_errors=False):
super().assert_reaches_phase(phase, msg_regexp, timeout, ignore_errors)

def assert_persist_phase(self, phase: Phase, msg_regexp=None, timeout=1000, ignore_errors=False, persist_for=1):
super().assert_persist_phase(phase, msg_regexp, timeout, ignore_errors, persist_for=persist_for)

def get_phase(self) -> Optional[Phase]:
try:
return Phase[self.ops_manager.get_status()["applicationDatabase"]["phase"]]
Expand Down Expand Up @@ -1159,6 +1191,9 @@ def assert_abandons_phase(self, phase: Phase, timeout=400):
def assert_reaches_phase(self, phase: Phase, msg_regexp=None, timeout=1200, ignore_errors=False):
super().assert_reaches_phase(phase, msg_regexp, timeout, ignore_errors)

def assert_persist_phase(self, phase: Phase, msg_regexp=None, timeout=1200, ignore_errors=False, persist_for=1):
super().assert_persist_phase(phase, msg_regexp, timeout, ignore_errors, persist_for=persist_for)

def get_phase(self) -> Optional[Phase]:
try:
return Phase[self.ops_manager.get_status()["opsManager"]["phase"]]
Expand Down
2 changes: 1 addition & 1 deletion ...netes-tests/tests/multicluster_appdb/multicluster_appdb_upgrade_downgrade_v1_27_to_mck.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -256,7 +256,7 @@ def test_scale_appdb(self, ops_manager: MongoDBOpsManager):
# Reordering the clusters triggers a change in the state
ops_manager["spec"]["applicationDatabase"]["clusterSpecList"] = scale_on_upgrade.cluster_spec
ops_manager.update()
ops_manager.appdb_status().assert_reaches_phase(Phase.Running, timeout=500)
ops_manager.appdb_status().assert_reaches_phase(Phase.Running, timeout=600)
ops_manager.om_status().assert_reaches_phase(Phase.Running, timeout=250)

def test_migrated_state_correctness(
Expand Down
2 changes: 1 addition & 1 deletion ...godb-kubernetes-tests/tests/multicluster_shardedcluster/multi_cluster_sharded_snippets.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -104,7 +104,7 @@ def test_running(namespace: str):
try:
logger.debug(f"Waiting for {sc.name} to reach Running phase")
# Once the first resource reached Running, it shouldn't take more than ~300s for the others to do so
sc.assert_reaches_phase(Phase.Running, timeout=900 if first_iter else 300)
sc.assert_reaches_phase(Phase.Running, timeout=1200 if first_iter else 300)
succeeded_resources.append(sc.name)
first_iter = False
logger.info(f"{sc.name} reached Running phase")
Expand Down
7 changes: 5 additions & 2 deletions docker/mongodb-kubernetes-tests/tests/upgrades/appdb_tls_operator_upgrade_v1_32_to_mck.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -161,8 +161,11 @@ def test_upgrade_operator(
@mark.e2e_appdb_tls_operator_upgrade_v1_32_to_mck
def test_om_tls_ok(ops_manager_tls: MongoDBOpsManager):
ops_manager_tls.load()
ops_manager_tls.appdb_status().assert_reaches_phase(Phase.Running, timeout=900)
ops_manager_tls.om_status().assert_reaches_phase(Phase.Running, timeout=900)
# We use assert_persist_phase here to ensure that the status stays in Running phase for some time,
# to avoid false positives due to a transient Running state before starting reconciliation of OM.
# TODO: Revert after fixing root issue (https://jira.mongodb.org/browse/CLOUDP-364841)
ops_manager_tls.appdb_status().assert_persist_phase(Phase.Running, timeout=900, persist_for=3)
ops_manager_tls.om_status().assert_persist_phase(Phase.Running, timeout=900, persist_for=3)
ops_manager_tls.get_om_tester().assert_healthiness()


Expand Down