Fix busy-poll when waiting on an in-progress project update - #405
Merged
Conversation
When a project already has an update in progress (most commonly the automatic update that fires right after an SCM project is created), wait_for_project_update() polled /project_updates/<id>/ in a tight loop with no delay until the update finished. The time.sleep(1) sat inside the is_job_done branch, so it only ran once the job was already done. The loop also ignored the wait, timeout, and interval parameters. Route this branch through the same wait_on_url() helper used by the explicit-update path so the interval and timeout are honored, the API is not hammered, and wait: false no longer blocks. Changed is now set from whether the SCM revision actually moved, matching the other path. This matches the behavior requested upstream in ansible/awx#12850. Add unit tests covering the wait, unchanged-revision, and wait: false cases for wait_for_project_update().
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes the awx.awx.project collection module’s wait_for_project_update() behavior when a project already has a sync/update in progress, avoiding a tight/busy polling loop and ensuring user-provided wait, timeout, and interval are respected.
Changes:
- Replaces the tight polling loop for an in-progress
current_updatewith the existingwait_on_url()helper (interval/timeout-aware and non-busy). - Ensures
wait: falsedoes not block when an update is already running. - Adds unit tests covering the in-progress-update path (including
interval/timeoutpassthrough), unchanged-SCM-revisionchanged: false, andwait: falsenon-blocking behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
awx_collection/plugins/modules/project.py |
Routes the “current update already running” case through wait_on_url() to honor wait/timeout/interval and avoid busy-polling. |
awx_collection/test/awx/test_project.py |
Adds targeted unit tests validating the non-busy wait behavior and correct changed semantics for the in-progress-update branch. |
cigamit
approved these changes
Jun 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SUMMARY
wait_for_project_update()inawx.awx.projectbusy-polled an in-progress project update.When a project already has an update running — most commonly the automatic update that fires right after an SCM project is created — the
current_updatebranch looped overGET /project_updates/<id>/with no delay between requests until the update finished. Thetime.sleep(1)was placed inside theis_job_done()check, so it only ever ran once the job was already done. The same branch also ignored the module'swait,timeout, andintervalparameters entirely:intervalignored — the user's polling interval had no effect.timeoutignored — a stuck update would loop forever.wait: falseignored — the task blocked unconditionally.This change routes the branch through the existing
wait_on_url()helper (the same one the explicitupdate_projectpath already uses), sointerval/timeoutare honored, the API is no longer hammered, andwait: falseno longer blocks.changedis now derived from whether the SCM revision actually moved, matching the other branch.This is the behavior requested upstream in ansible/awx#12850 — the busy-poll is still present in current upstream
devel, so this fix is equally applicable there.ISSUE TYPE
COMPONENT NAME
ASCENDER VERSION
ADDITIONAL INFORMATION
Reproduction (before this change): create a new git-backed project with the default
wait: true. The module fires the automatic post-create update and lands in thecurrent_updatebranch, which polls/api/v2/project_updates/<id>/in a tight loop with no delay until the sync finishes.Tests: added unit tests for
wait_for_project_update()covering the in-progress-update wait path (assertswait_on_urlis called with the configuredtimeout/intervaland that the endpoint is not busy-polled), the unchanged-SCM-revisionchanged: falsecase, and thewait: falsenon-blocking case.(The three pre-existing
run_module-based tests in this file fail identically on unmodifiedmaindue to an unrelated ansible-core/test-harness incompatibility inexit_json; they are not affected by this change.)