Skip to content

e2e: tolerate transient errors in Eventually#3907

Open
gman0 wants to merge 2 commits intokcp-dev:mainfrom
gman0:e2e-eventually-cleanup
Open

e2e: tolerate transient errors in Eventually#3907
gman0 wants to merge 2 commits intokcp-dev:mainfrom
gman0:e2e-eventually-cleanup

Conversation

@gman0
Copy link
Contributor

@gman0 gman0 commented Mar 16, 2026

Summary

There are a few e2e tests that fail on errors that may be only transient. This PR adds a helper function TolerateOrFail depending on the supplied predicates and tolerates/fails accordingly. It's being called where appropriate: as far as I could tell, these are the last places that were left after the other Eventually() VS require.* cleanups we had.

What Type of PR Is This?

/kind cleanup

Related Issue(s)

Fixes #3905

Release Notes

NONE

On-behalf-of: @SAP robert.vasek@sap.com
Signed-off-by: Robert Vasek <robert.vasek@clyso.com>
@kcp-ci-bot kcp-ci-bot added release-note-none Denotes a PR that doesn't merit a release note. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. dco-signoff: yes Indicates the PR's author has signed the DCO. labels Mar 16, 2026
@kcp-ci-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign embik for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kcp-ci-bot kcp-ci-bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Mar 16, 2026
@gman0
Copy link
Contributor Author

gman0 commented Mar 16, 2026

Also, I think our error handling in tests could use some work. E.g. it seems, as time went on, the different kcptestinghelpers.Eventually, require.Eventually, and require.EventuallyWithT retry-able functions have been used, and it's a bit of a mess. IMHO we should pick one and stick with it.

I'd be really happy if someone more knowledgeable around testing frameworks could give their few cents and say if there are any ideas worth borrowing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dco-signoff: yes Indicates the PR's author has signed the DCO. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cleanup: e2e: validate usage of require.* assertions in Eventually

2 participants