Fix flaky RecoveryTimeout e2e test

[sohankunkerkar]

I think this test uses RecoveryTimeout: 10ms to validate eviction behavior. With such a small timeout, multiple evictions can happen quickly. After a pod failure, the workload gets re-admitted in ~50ms, but since RecoveryTimeout is only 10ms, if the pods aren’t Ready yet, a second eviction is triggered before they become Ready and before RequeueState is cleared.

With BackoffLimitCount: 1, the first eviction increments the count to 1. When the second eviction occurs, the condition count+1 > BackoffLimitCount (i.e., 1+1 > 1) evaluates to true, which causes a deactivation and clears RequeueState entirely.

Increasing RecoveryTimeout would defeat the purpose of the test, which is specifically testing behavior with a tiny RecoveryTimeout.

What type of PR is this?

/kind flake

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #5106

Special notes for your reviewer:

Does this PR introduce a user-facing change?

None

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue canceled.

Name	Link
🔨 Latest commit	ddb2f1f
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-kueue/deploys/6935d5fab1550a0008d3c3ef

[Copilot]

Pull request overview

This PR addresses a flaky end-to-end test that validates workload eviction and requeue behavior with a tiny RecoveryTimeout (10ms). The flakiness occurred because multiple evictions could happen rapidly before pods became Ready, causing premature deactivation with the original BackoffLimitCount: 1.

Key changes:

• Increased BackoffLimitCount from 1 to 2 to allow multiple eviction cycles before deactivation
• Updated test assertions to use >=1 comparisons instead of exact counts to accommodate multiple evictions
• Replaced struct comparison with individual field assertions for better test clarity

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] The comment states "Allow at least one requeue cycle before deactivation" but with BackoffLimitCount: 2, the workload would be deactivated when count+1 > BackoffLimitCount, i.e., when count+1 > 2, which means deactivation occurs when count reaches 2 (since 2+1 > 2). This allows for 2 evictions before deactivation, not just "at least one requeue cycle."

Consider clarifying the comment to be more precise:

// Allow up to 2 evictions before deactivation so the test
// can verify the requeue behavior even if multiple evictions occur.

Suggested change

	// Allow at least one requeue cycle before deactivation so the test
	// can verify the requeue behavior.
	// Allow up to 2 evictions before deactivation so the test
	// can verify the requeue behavior even if multiple evictions occur.

[sohankunkerkar]

/retest

[sohankunkerkar]

/retest

[mimowo]

/retest

[mimowo]

Thank you, this makes sense 👍
/lgtm
/approve
/cherrypick release-0.15
/cherrypick release-0.14

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: f7fe0a7671efd40cc2b3066d4abdfb5f0854d434

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mimowo, sohankunkerkar

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mimowo]

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