[Docs] Added docs on how to handle a large response when using FlyteRemote.sync

rsts/community/troubleshoot.rst

@@ -112,7 +112,11 @@ Troubles With Inconsistent Names for Pods and Downstream Resources
 - Flyte uses the format ``executionid-node-id-attempt`` from the node to assign a name to a Kubernetes pod or downstream resource.
 - But if this is an invalid name for a Kubernetes pod, Flyte assigns a valid name of random characters instead.
 
+Troubles with handling large responses in ``FlyteRemote.sync`` 
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+- ``Received message larger than max (xxx vs. 4194304)`` usually crops up when the message size is too large.
+- To fix this, edit the ``flyte-admin-base-config`` config map using the command ``kubectl edit cm flyte-admin-base-config -n flyte`` to increase the ``maxMessageSizeBytes`` value.
 
 
 I Still Need Help!

rsts/concepts/data_management.rst

@@ -166,8 +166,8 @@ Between Tasks
 Bringing in Your Own Datastores for Raw Data
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Flytekit has a pluggable data persistence layer as explained in :std:ref:`data.extend:extend data persistence layer`. This is driven by PROTOCOL.
+Flytekit has a pluggable data persistence layer as explained in :ref:`extend data persistence layer <https://docs.flyte.org/projects/flytekit/en/latest/data.extend.html#data-persistence-layer>`. This is driven by PROTOCOL.
 For example, it is theoretically possible to use S3 ``s3://`` for metadata and GCS ``gcs://`` for raw data. It is also possible to create your own protocol ``my_fs://``, to change how data is stored and accessed.
 But for Metadata, the data should be accessible to Flyte control plane.
 
-Data persistence is also pluggable. By default, it supports all major blob stores and uses an interface defined in Flytestdlib.
+Data persistence is also pluggable. By default, it supports all major blob stores and uses an interface defined in Flytestdlib.