Skip to content

fix: scheduler container supervises scheduler instead of dag-processor - #847

Open
sweb wants to merge 4 commits into
mainfrom
fix/supervise-scheduler
Open

fix: scheduler container supervises scheduler instead of dag-processor#847
sweb wants to merge 4 commits into
mainfrom
fix/supervise-scheduler

Conversation

@sweb

@sweb sweb commented Aug 17, 2026

Copy link
Copy Markdown
Member

Description

With Airflow 3, the dag processor was supervised instead of the scheduler in the scheduler container. When the scheduler process died, the pod would not terminate and continue to declare itself as healthy even though nothing would get scheduled.

Definition of Done Checklist

  • Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
  • Please make sure all these things are done and tick the boxes

Author

  • Changes are OpenShift compatible
  • CRD changes approved
  • CRD documentation for all fields, following the style guide.
  • Helm chart can be installed and deployed operator works
  • Integration tests passed (for non trivial changes)
  • Changes need to be "offline" compatible
  • Links to generated (nightly) docs added
  • Release note snippet added

Reviewer

  • Code contains useful comments
  • Code contains useful logging statements
  • (Integration-)Test cases added
  • Documentation added or updated. Follows the style guide.
  • Changelog updated
  • Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

  • Feature Tracker has been updated
  • Proper release label has been added
  • Links to generated (nightly) docs added
  • Release note snippet added
  • Add type/deprecation label & add to the deprecation schedule
  • Add type/experimental label & add to the experimental features tracker

@sweb
sweb force-pushed the fix/supervise-scheduler branch from c72a2ee to d54206d Compare August 17, 2026 06:32
@sweb
sweb force-pushed the fix/supervise-scheduler branch from e1bdc87 to 363fb7c Compare August 17, 2026 09:34
@sweb sweb self-assigned this Aug 17, 2026
@sweb sweb moved this to Development: Waiting for Review in Stackable Engineering Aug 17, 2026
@razvan
razvan self-requested a review August 18, 2026 06:49
@razvan razvan moved this from Development: Waiting for Review to Development: In Review in Stackable Engineering Aug 18, 2026
// the scheduler.
command.extend(vec!["airflow dag-processor &".to_string()]);
}
command.extend(vec!["airflow scheduler &".to_string()]);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So previously the scheduler was ignored and now the dag-processor is ignored.

Shouldn't they both be tracked?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll look into how to track both 👍

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see how this would escalate into a much larger refactoring and raise again the question if it's a good idea to stitch together shell scripts in rust code.

So feel free to skip if that happens.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One idea here: Ditch the current mechanic and utilize probes - at least the scheduler has an API you can call to check if everything is ok.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One goal of the current bash-fu was to ensure that products get a chance to react to SIGTERM and do a "graceful" shutdown.
Probes alone cannot do that. Maybe in combination with a container preStop command ?


import requests

HEALTH_URL = "http://airflow-webserver:8080/api/v2/monitor/health"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a "nice to have", maybe this can be incorporated in commons/health.py to reduce duplication and increase coverage in other tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Development: In Review

Development

Successfully merging this pull request may close these issues.

2 participants