Add no-op _process_workloads to EdgeExecutor to improve readability

[wjddn279]

Why?

Unlike other Executors, EdgeExecutor does not process workloads in trigger_tasks, so _process_workloads was not overridden. However, this can cause confusion for people (myself included) who are accustomed to other executors when they first encounter it.

I've implemented an explicit no-op implementation with a docstring explaining why the method is intentionally unused, to prevent confusion for future contributors and avoid a potential NotImplementedError if the base class flow ever changes.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[Nataneljpwd]

Great addition!
It enhanced the readability and ease of understanding of the executor!

[jscheffl]

I am wondering a bit though why this internal method is expected to be implemented,.

Can you please adjust also the documentation in https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/executor/index.html#important-baseexecutor-methods - because it is not mentioned there and I am wondering why the base executor raises an exception here. I do not see why (all) executors need to implement it. I would consider it beed to be changes in Base class rather if it is optional.

[wjddn279]

@jscheffl
Looking at the implementation and comments of BaseExecutor's _process_workloads.

airflow/airflow-core/src/airflow/executors/base_executor.py

Lines 265 to 275 in 28f7cf8

	def _process_workloads(self, workloads: Sequence[workloads.All]) -> None:
	"""
	Process the given workloads.
	This method must be implemented by subclasses to define how they handle
	the execution of workloads (e.g., queuing them to workers, submitting to
	external systems, etc.).
	:param workloads: List of workloads to process
	"""
	raise NotImplementedError(f"{type(self).__name__} must implement _process_workloads()")

It's defined as something subclasses must implement. The reason it's enforced is that all objects inheriting from BaseExecutor are assumed to follow the pattern of queuing tasks into an internal queue via queue_workload and processing them in _process_workloads.

EdgeExecutor is the only case (so far) that doesn't follow this pattern. However, as long as it inherits from BaseExecutor, I believe it should still implement _process_workloads and explicitly state that it's an exception case, even if it's not actually used.

To be precise, I think BaseExecutor should ideally be split — something like BaseExecutorWithQueue and BaseExecutorWithoutQueue. But since EdgeExecutor is the only such case, that feels like overkill for now. (Though it should be revisited if more cases come up.)

[jscheffl]

It's defined as something subclasses must implement.

And therefore I wrote earlier: Can you please adjust also the documentation in https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/executor/index.html#important-baseexecutor-methods - because it is not mentioned there

[wjddn279]

added!

[jscheffl]

Thanks for adding the docs!

[github-actions]

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.1.9 based on: backport label targeting v3-1-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[github-actions]

Backport successfully created: v3-1-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-1-test