Dirk JulichandClaude Opus 4.6
dad4da74b9
* Fix 500 error on /api/v2/schedules/ from orphaned token cleanup schedule delete_clear_tokens_sjt() relied on cascade to remove the associated schedule when deleting the cleanup_tokens SystemJobTemplate. In migration context with polymorphic models, the cascade did not reliably fire, leaving an orphaned schedule whose unified_job_template referenced a missing row. Explicitly delete associated schedules and clear stale next_schedule references before deleting the SJT. Add defensive handling in ScheduleSerializer.get_related() and get_summary_fields() so orphaned schedules degrade gracefully instead of raising RelatedObjectDoesNotExist. Fix the existing test assertion that used a JOIN-based query incapable of detecting orphans, and add coverage for next_schedule reference cleanup. Fixes: AAP-92564 * Add migration to clean up orphaned token cleanup schedules Databases that already ran migration 0204 may have orphaned "Cleanup Expired OAuth 2 Tokens" schedules left behind by the broken cascade. Remove them and clear any stale UnifiedJobTemplate.next_schedule references. Add a test that simulates the orphan scenario by deleting the UJT via raw SQL and verifying the migration repairs it. Ref: AAP-92564 * Re-parent migration 0212 for gateway backport to stable-2.7 Apply the gateway backport migration pattern (AAP-87599): re-parent 0212_cleanup_orphaned_token_schedules to depend on 0207_merge (the common ancestor with tower/stable-2.7) instead of 0211. Add 0213_merge_0211_0212 to converge the parallel paths on devel. This allows the backport to tower/stable-2.7 to use the identical 0212 migration file with no changes. Ref: AAP-92564 * Test next_schedule cleanup on a surviving template Use the cleanup_sessions SystemJobTemplate (which survives the deletion) as the next_schedule reference holder, so the assertion actually proves the UPDATE ... SET next_schedule = NULL logic works rather than being masked by the referenced UJT itself being deleted. Ref: AAP-92564 * Fix test: create surviving SJT instead of relying on migration data The CI test DB does not have the cleanup_sessions SystemJobTemplate from migration 0078. Use get_or_create to ensure the surviving UJT exists within the test itself. Ref: AAP-92564 * Renumber cleanup migration to 0208 and bump 0208-0211 to 0209-0212 Replace the gateway backport pattern (re-parented migration + merge migration) with a simpler approach: slot the cleanup migration as 0208 directly after the merge point, and renumber the subsequent migrations. This keeps the migration graph linear on all branches and preserves the ability to backport 0209-0212 individually in the future. Ref: AAP-92564 --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Caution
The last release of this repository was released on Jul 2, 2024. Releases of this project are now paused during a large scale refactoring. For more information, follow the Forum and - more specifically - see the various communications on the matter:
AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
To install AWX, please view the Install guide.
To learn more about using AWX, view the AWX docs site.
The AWX Project Frequently Asked Questions can be found here.
The AWX logos and branding assets are covered by our trademark guidelines.
Contributing
- Refer to the Contributing guide to get started developing, testing, and building AWX.
- All code submissions are made through pull requests against the
develbranch. - All contributors must use
git commit --signofffor any commit to be merged and agree that usage of--signoffconstitutes agreement with the terms of DCO 1.1 - Take care to make sure no merge commits are in the submission, and use
git rebasevs.git mergefor this reason. - If submitting a large code change, it's a good idea to join discuss via the Ansible Forum. This helps everyone know what's going on, and it also helps save time and effort if the community decides some changes are needed.
Reporting Issues
If you're experiencing a problem that you feel is a bug in AWX or have ideas for improving AWX, we encourage you to open an issue and share your feedback. But before opening a new issue, we ask that you please take a look at our Issues guide.
Code of Conduct
We require all of our community members and contributors to adhere to the Ansible code of conduct. If you have questions or need assistance, please reach out to our community team at codeofconduct@ansible.com
Get Involved
We welcome your feedback and ideas via the Ansible Forum.
For a full list of all the ways to talk with the Ansible Community, see the AWX Communication guide.