You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2026/08/24 00:08:00 UTC
[jira] [Updated] (YUNIKORN-3399) Align RollbackAllocation tests with the ask-presence guard from YUNIKORN-3360
[ https://issues.apache.org/jira/browse/YUNIKORN-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated YUNIKORN-3399:
-------------------------------------
Labels: pull-request-available (was: )
> Align RollbackAllocation tests with the ask-presence guard from YUNIKORN-3360
> -----------------------------------------------------------------------------
>
> Key: YUNIKORN-3399
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3399
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: core - scheduler
> Reporter: Dale Richardson
> Assignee: Dale Richardson
> Priority: Major
> Labels: pull-request-available
>
> h3. Problem
> {{make test}} fails on master with two failures in {{{}pkg/scheduler/objects{}}}:
> * {{TestRollbackAllocationAskNotTracked}} — {{failed to locate ask with key alloc-1 for rollback: rollback of the confirmed allocation should have succeeded}}
> * {{TestApplicationPropertyFuzzHistogram}} — {{totalGhostRollbacks is <= 0: no seed ever rolled back an ask missing from sa.requests}}
> Both fail deterministically on a clean master checkout; nothing else in the package fails.
> h3. Cause
> A semantic conflict between two independently merged PRs. There was no textual conflict, so both merged cleanly:
> * YUNIKORN-3360 (commit 52aca85, merged 2026-08-18) added a guard to {{{}RollbackAllocation{}}}: the rollback is now rejected when {{sa.requests}} no longer holds the ask.
> * YUNIKORN-3352 (commit 2a271ec, merged 2026-08-20) added tests written against the pre-3360 behaviour, where rolling back such a "ghost" allocation (ask already dropped from {{{}sa.requests{}}}, allocation still in {{sa.allocations}} awaiting shim confirmation) succeeded:
> ** {{TestRollbackAllocationAskNotTracked}} asserts the ghost rollback succeeds and leaves the pending histogram untouched.
> ** {{TestApplicationPropertyFuzzHistogram}} asserts at least one fuzz seed performed a successful ghost rollback, as a coverage guarantee for that path.
> With the guard in place a ghost rollback always returns an error, so both assertions can no longer hold.
> h3. Fix
> Test-only change; pins the YUNIKORN-3360 semantics:
> * {{{}TestRollbackAllocationAskNotTracked{}}}: assert the rollback is rejected and that application state (pending histogram, askMaxPriority, pending resource, allocations) is unchanged.
> * {{{}TestApplicationPropertyFuzzHistogram{}}}: the fuzzer's reference model already treats a rollback error as a no-op, so only the coverage assertion changes — count ghost rollbacks that were attempted and rejected rather than ones that succeeded.
> h3. Note
> The YUNIKORN-3360 guard was added on the assumption the ask is always present. The ghost state is reachable: {{removeAsksInternal("")}} wipes {{sa.requests}} while {{sa.allocations}} survives until the shim confirms the releases, and a {{SCHEDULING_FAILED_ON_RM}} release arriving in that window reaches {{{}RollbackAllocation{}}}. With the guard, that release is now dropped without removing the allocation from the application, node or queue. That question is independent of the test breakage and will be raised on YUNIKORN-3360; this issue only fixes the tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org