BaseMessageQueueProvider declares abstractmethods without ABC, and three in-tree providers do not implement them

[keith991001]

Body

While adding the missing test module for common.messaging (#72915, part of #35442) I found the provider base-class contract is out of sync with its implementations:

1. The abstract contract is not enforced. BaseMessageQueueProvider decorates queue_matches / trigger_class / trigger_kwargs with @abstractmethod, but the class does not inherit abc.ABC, so nothing blocks instantiating an incomplete subclass. Calling an unimplemented "abstract" method silently returns None, which in MessageQueueTrigger.trigger dispatch makes the provider silently never match by queue instead of failing loudly.

2. Three in-tree providers rely on that gap. PubSubMessageQueueEventTriggerContainer (google), RedisPubSubMessageQueueProvider (redis), and AzureServiceBusMessageQueueProvider (microsoft.azure) implement only trigger_class + the scheme attribute — they support the scheme-based dispatch path only, and would fail to instantiate if abc.ABC were simply added. The older providers (amazon sqs, apache.kafka, ibm.mq) implement all three.

So the fix is a design decision rather than a mechanical change. Options as I see them:

• (a) Inherit abc.ABC, and demote queue_matches / trigger_kwargs from abstract to concrete defaults (return False / return {}) documented as "override for queue-URI dispatch" — keeps trigger_class as the only hard requirement, matches what the three scheme-only providers already assume, and no provider changes needed.
• (b) Inherit abc.ABC keeping all three abstract, and add the two missing methods to the three scheme-only providers.
• (c) Keep the class as-is and only fix the docstrings to say which methods are required for which dispatch path (no enforcement).

Happy to implement whichever direction maintainers prefer.

Committer

• I acknowledge that I am a maintainer/committer of the Apache Airflow project.

[AbarnaaSree]

Hi @keith991001, I’d like to work on this issue.

The mismatch between the abstract contract and the existing scheme-only providers makes this a useful cleanup, especially since the current @abstractmethod declarations are not actually enforced.

I’d like to first trace the BaseMessageQueueProvider dispatch flow and existing provider implementations/tests, then implement the direction preferred by the maintainers while adding regression coverage for both queue-based and scheme-based providers.

If you’re okay with that approach, I’d be happy to submit a PR.