[GitHub] [airflow] uranusjr commented on a change in pull request #20755: Augment xcom docs

[GitBox <gi...@apache.org>]

uranusjr commented on a change in pull request #20755:
URL: https://github.com/apache/airflow/pull/20755#discussion_r780623923



##########
File path: docs/apache-airflow/concepts/xcoms.rst
##########
@@ -42,13 +42,63 @@ XComs are a relative of :doc:`variables`, with the main difference being that XC
 
   Note: If the first task run is not succeeded then on every retry task XComs will be cleared to make the task run idempotent.
 
-Custom Backends
----------------
+Custom XCom Backends
+--------------------
 
 The XCom system has interchangeable backends, and you can set which backend is being used via the ``xcom_backend`` configuration option.
 
 If you want to implement your own backend, you should subclass :class:`~airflow.models.xcom.BaseXCom`, and override the ``serialize_value`` and ``deserialize_value`` methods.
 
 There is also an ``orm_deserialize_value`` method that is called whenever the XCom objects are rendered for UI or reporting purposes; if you have large or expensive-to-retrieve values in your XComs, you should override this method to avoid calling that code (and instead return a lighter, incomplete representation) so the UI remains responsive.
 
-You can also override the ``clear`` method and use it when clearing results for given dags and tasks. This allows the custom XCom backend process the data lifecycle easier.
+You can also override the ``clear`` method and use it when clearing results for given dags and tasks. This allows the custom XCom backend to process the data lifecycle easier.
+
+Working with Custom XCom Backends in Containers
+-----------------------------------------------
+
+Depending on where Airflow is deployed i.e., local, Docker, K8s, etc. it can be useful to be assured that a custom XCom backend is actually being initialized. For example, the complexity of the container environment can make it more difficult to determine if your backend is being loaded correctly during container deployment. Luckily the following guidance can be used to assist you in building confidence in your custom XCom implementation.
+
+Firstly, if you can exec into a terminal in the container then you should be able to do::
+
+    from  airflow.models.xcom  import XCom
+    print(XCom.__name__)

Review comment:
       ```suggestion
   Firstly, if you can exec into a terminal in the container then you should be able to do:
   
   .. code-block:: python
   
       from airflow.models.xcom import XCom
       print(XCom.__name__)
   ```
   
   Better syntax highlighting. Same for the conf code blocks below.

##########
File path: docs/apache-airflow/concepts/xcoms.rst
##########
@@ -42,13 +42,63 @@ XComs are a relative of :doc:`variables`, with the main difference being that XC
 
   Note: If the first task run is not succeeded then on every retry task XComs will be cleared to make the task run idempotent.
 
-Custom Backends
----------------
+Custom XCom Backends
+--------------------
 
 The XCom system has interchangeable backends, and you can set which backend is being used via the ``xcom_backend`` configuration option.
 
 If you want to implement your own backend, you should subclass :class:`~airflow.models.xcom.BaseXCom`, and override the ``serialize_value`` and ``deserialize_value`` methods.
 
 There is also an ``orm_deserialize_value`` method that is called whenever the XCom objects are rendered for UI or reporting purposes; if you have large or expensive-to-retrieve values in your XComs, you should override this method to avoid calling that code (and instead return a lighter, incomplete representation) so the UI remains responsive.
 
-You can also override the ``clear`` method and use it when clearing results for given dags and tasks. This allows the custom XCom backend process the data lifecycle easier.
+You can also override the ``clear`` method and use it when clearing results for given dags and tasks. This allows the custom XCom backend to process the data lifecycle easier.
+
+Working with Custom XCom Backends in Containers
+-----------------------------------------------
+
+Depending on where Airflow is deployed i.e., local, Docker, K8s, etc. it can be useful to be assured that a custom XCom backend is actually being initialized. For example, the complexity of the container environment can make it more difficult to determine if your backend is being loaded correctly during container deployment. Luckily the following guidance can be used to assist you in building confidence in your custom XCom implementation.
+
+Firstly, if you can exec into a terminal in the container then you should be able to do::
+
+    from  airflow.models.xcom  import XCom
+    print(XCom.__name__)
+
+which will print the actual class that is being used.
+
+Depending on how you've configured the backend, you can also examine airflow
+configuration::
+
+    from airflow.settings import conf
+    conf.get("core", "xcom_backend")
+
+If using env vars check  with ``env|grep  AIRFLOW__CORE__XCOM``.

Review comment:
       ```suggestion
   If using env vars, check with ``env|grep  AIRFLOW__CORE__XCOM``.
   ```




-- 
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: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org