test-infra
test-infra copied to clipboard
kubernetes
[Flaky Test] unit-test-race-detector-nonblocking
What happened: I see that the unit-test-race-detector-nonblocking fails somewhat often. What you expected to happen: Test succeeds. How to reproduce it (as minimally and precisely as possible):
Please provide links to example occurrences, if any: https://testgrid.k8s.io/presubmits-test-infra#unit-test-race-detector-nonblocking Anything else we need to know?:
@pohly @aojea , it looks like we're still using the hashicorp simple-lru package in a prow Cache. There are a few interfaces missing from the forked golang-lru (specifically Keys(). I'm not 100% confident that moving from simplelru to the community golang-lru will solve this specific issue, but would you support transitioning to the community package? I'm happy to do the legwork to transition.
Sounds like a useful thing to do. However, I have very little experience with Prow source code, so it would be better to get confirmation from someone who knows it better and then can also review a PR.
After some more testing it looks like switching from the hashicorp package will add some stability to this test. I'm working out where to add the Keys() implementation.
It looks like #31220 did resolve a significant number of flakes from TestGetProwYAMLCached. I don't see any occurrences of that test flaking since that PR. https://storage.googleapis.com/k8s-triage/index.html?date=2023-11-21&pr=1&job=pull-test-infra-unit-test-race-detector-nonblocking#26968037200eacffed78 https://storage.googleapis.com/k8s-triage/index.html?date=2023-11-21&pr=1&job=pull-test-infra-unit-test-race-detector-nonblocking#ecdf8f05dd4ce46ab0a2
I'm not sure if this is sufficient to resolve this issue as unit-test-race-detector-nonblocking is still failing quite frequently but doesn't seem to be flaking on specific jobs compared to before.
Revert created at https://github.com/kubernetes/test-infra/pull/31390. Please take a look, thanks.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
