potiuk commented on code in PR #53556:
URL: https://github.com/apache/airflow/pull/53556#discussion_r2256680902


##########
providers/redis/src/airflow/providers/redis/queues/redis.py:
##########
@@ -0,0 +1,91 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+from __future__ import annotations
+
+import re
+from typing import TYPE_CHECKING
+from urllib.parse import urlparse
+
+from airflow.providers.common.messaging.providers.base_provider import 
BaseMessageQueueProvider
+from airflow.providers.redis.triggers.redis_await_message import 
AwaitMessageTrigger
+
+if TYPE_CHECKING:
+    from airflow.triggers.base import BaseEventTrigger
+
+# [START queue_regexp]
+QUEUE_REGEXP = r"^redis\+pubsub://"
+# [END queue_regexp]
+
+
+class RedisPubSubMessageQueueProvider(BaseMessageQueueProvider):
+    """
+    Configuration for Redis integration with common-messaging.
+
+    It uses the ``redis+pubsub://`` URI scheme for identifying Redis queues.
+
+    **URI Format**:
+
+    .. code-block:: text
+
+        redis+pubsub://<host>:<port>/<channel_list>
+
+    Where:
+
+    * ``host``: Redis server hostname
+    * ``port``: Redis server port
+    * ``channel_list``: Comma-separated list of Redis channels to subscribe to
+
+    **Examples**:
+
+    .. code-block:: text
+
+        redis+pubsub://localhost:6379/my_channel
+
+    You can also provide ``channels`` directly in kwargs instead of in the URI.
+
+    .. code-block:: python
+
+        from airflow.providers.common.messaging.triggers.msg_queue import 
MessageQueueTrigger
+
+        trigger = 
MessageQueueTrigger(queue="redis+pubsub://localhost:6379/test")
+
+    For a complete example, see:
+    :mod:`tests.system.redis.example_dag_message_queue_trigger`
+    """
+
+    def queue_matches(self, queue: str) -> bool:
+        return bool(re.match(QUEUE_REGEXP, queue))
+
+    def trigger_class(self) -> type[BaseEventTrigger]:
+        return AwaitMessageTrigger  # type: ignore[return-value]
+
+    def trigger_kwargs(self, queue: str, **kwargs) -> dict:
+        # [START extract_channels]
+        # Parse the queue URI
+        parsed = urlparse(queue)
+        # Extract channels (after host and port)
+        # parsed.path starts with a '/', so strip it
+        raw_channels = parsed.path.lstrip("/")
+        channels = raw_channels.split(",") if raw_channels else []
+        # [END extract_channels]
+
+        if not channels and "channels" not in kwargs:
+            raise ValueError(
+                "channels is required in RedisPubSubMessageQueueProvider 
kwargs or provide them in the queue URI"
+            )
+
+        return {} if "channels" in kwargs else {"channels": channels}

Review Comment:
   > As shown in https://github.com/apache/airflow/pull/51718, the developer 
experience can suffer when some parameters are included in the URI while others 
are passed separately through kwargs.
   IMO, it should be clearer for users and also help maintain a flexible and 
"common" interface, while still promoting a clean and consistent usage pattern.
   
   I think it also depends - there are cases where sensitive or dangerous 
information should not be put in "externally" provided data and **should** be 
added by DagAuthor - this is the question of our security model - for example 
it impacts some of the decisions on some providers, where certain "features" 
can only be enabled or certain "parameters" should be specified only by Dag 
Author - not the user in the UI - via parameters or connections.
   
   I am not sure if there is such case here, but just wanted to stress in this 
case security trumps both convenience for developer and consistency.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to