Skip to content

test(atecontroller): retry the WorkerPool update on conflict - #995

Open
NekoPunch (orangeCatDeveloper) wants to merge 1 commit into
agent-substrate:mainfrom
orangeCatDeveloper:fix/workerpool-template-update-conflict
Open

test(atecontroller): retry the WorkerPool update on conflict#995
NekoPunch (orangeCatDeveloper) wants to merge 1 commit into
agent-substrate:mainfrom
orangeCatDeveloper:fix/workerpool-template-update-conflict

Conversation

@orangeCatDeveloper

@orangeCatDeveloper NekoPunch (orangeCatDeveloper) commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Fixes #994

TestWorkerPoolPodTemplateUpdate intermittently fails on main with:

Operation cannot be fulfilled on workerpools.ate.dev "test-template-update":
the object has been modified; please apply your changes to the latest version and try again

Three runs on main carry it, each verified to fail on this test with this signature:

The test read the WorkerPool and wrote it back without handling conflicts, while WorkerPoolReconciler writes the same object's status (workerpool_controller.go:142) and bumps its resourceVersion. A reconcile landing between the read and the write rejects it. The file already has updateWorkerPoolSpec, which re-reads and retries on conflict — and the comment on its sibling describes this exact failure — so this just uses it.

Verification

-count=N proves nothing here: the unfixed test passes at -count=100 -race locally because the window is too narrow to hit by chance. I constructed the conflict instead, inserting a write between the test's read and its write:

result
bare get-then-update fails with the CI error verbatim: Operation cannot be fulfilled on workerpools.ate.dev "race-probe-bare": the object has been modified; please apply your changes to the latest version and try again
via updateWorkerPoolSpec retries, succeeds, and the change lands (verified NodeSelector is updated afterwards)

The probe tests were only for this and are not included.

Scope: this shows the race is real and that the helper handles it. It does not prove the three CI failures took this exact path — the constructed contention is a manual write, whereas on CI it is the reconciler's status update. The error signature, the cause in the code, and the pre-existing helper all line up, but that last step is inference.

I checked the other Update call sites in this file; they already go through the retry helpers.

TestWorkerPoolPodTemplateUpdate did a bare get-then-update while the
reconciler writes the same object's status, so a reconcile landing between
the read and the write rejected it with "the object has been modified".
The file already has updateWorkerPoolSpec for this; use it.

Claude-Session: https://claude.ai/code/session_01XuQqkwLf5Zx6CSZFHSC6hb
@orangeCatDeveloper
NekoPunch (orangeCatDeveloper) force-pushed the fix/workerpool-template-update-conflict branch from 9b30748 to 67e1739 Compare August 18, 2026 01:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

E2E test flake: TestWorkerPoolPodTemplateUpdate fails on optimistic-concurrency conflict

1 participant