Making ResumableJobMixin a abstract class and its methods abstractmet…

[amoghrajesh]

…hods

---

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

• Yes - claude sonnet 4.6

What

ResumableJobMixin's six subclass-facing methods (submit_job, get_job_status, is_job_active, is_job_succeeded, poll_until_complete, get_job_result) are the entire contract a subclass must fulfill to get crash-safe execution. Today, if an implementer forgets to override one, the class still constructs fine and the mistake only surfaces as a NotImplementedError the first time that specific method is actually called, which can be much later than when the operator was defined.

Current behaviour

A subclass missing, say, get_job_result instantiates without complaint. The gap is invisible until a task actually reaches that code path, which for methods like poll_until_complete's reconnect branch might only happen after a real worker crash in production, long after the operator shipped.

Proposed change

ResumableJobMixin now inherits from ABC and decorates all six methods with @abstractmethod. BaseOperatorMeta (the metaclass every BaseOperator subclass already uses) already inherits from ABCMeta, so this composes with (ResumableJobMixin, BaseOperator) with zero metaclass conflict.

Why all six must be overridden

• The mixin has no reasonable default for any of them and each one is where the subclass's specific external system (Databricks, Snowflake, etc.) actually gets talked to, and execute_resumable()'s control flow calls all six depending on which branch it takes (fresh submit, reconnect, already-succeeded, terminal failure).

• A subclass that's missing even one of them isn't "mostly correct", it has a hole in the exact contract this mixin exists to provide, and today that hole is silent until runtime. Marking them abstract moves the failure from "the first time this specific code path executes, maybe in production during an actual crash" to "the moment the class is defined," which is a strictly better place to catch it, a missing override bug should fail at parse/import time, not lie dormant until an operator's least-tested branch (e.g. reconnect-on-crash) finally runs for real.

User implications / backcompat

• No behavior change for any correctly-implemented subclass such as DatabricksSubmitRunOperator, DatabricksRunNowOperator, and SparkSubmitOperator (all currently shipped) already override every one of the six methods, so nothing changes for them; overriding an abstract method works identically to overriding a regular one.

---

• 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.