Merge pull request #281483 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: PhilKang0704

articles/azure-functions/functions-reference-java.md

@@ -93,7 +93,7 @@ FunctionsProject
 
 You can use a shared [host.json](functions-host-json.md) file to configure the function app. Each function has its own code file (.java) and binding configuration file (function.json).
 
-You can put more than one function in a project. Avoid putting your functions into separate jars. The `FunctionApp` in the target directory is what gets deployed to your function app in Azure.
+You can have more than one function in a project. However, don't put your functions into separate jars. Using multiple jars in a single function app isn't supported. The `FunctionApp` in the target directory is what gets deployed to your function app in Azure.
 
 ## Triggers and annotations
 

articles/azure-resource-manager/management/tag-resources.md

@@ -61,6 +61,12 @@ You can retrieve information about tags by downloading the usage file available
 
 For REST API operations, see [Azure Billing REST API Reference](/rest/api/billing/).
 
+## Unique tags pagination 
+
+When calling the [Unique Tags API](/rest/api/resources/tags/list) there is a limit to the size of each API response page that is returned. A tag that has a large set of unique values will require the API to fetch the next page to retrieve the remaining set of values. When this happens the tag key is shown again to indicate that the vales are still under this key.  
+
+This can result in some tools, like the Azure portal, to show the tag key twice.  
+
 ## Limitations
 
 The following limitations apply to tags:

articles/kubernetes-fleet/concepts-resource-propagation.md

@@ -79,7 +79,7 @@ Multiple placement types are available for controlling the number of clusters to
 
 You can use a `PickAll` placement policy to deploy a workload across all member clusters in the fleet (optionally matching a set of criteria).
 
-The following example shows how to deploy a `test-deployment` namespace and all of its objects across all clusters labeled with `environment: production`:
+The following example shows how to deploy a `prod-deployment` namespace and all of its objects across all clusters labeled with `environment: production`:
 
 ```yaml
 apiVersion: placement.kubernetes-fleet.io/v1beta1
@@ -103,7 +103,7 @@ spec:
       version: v1
 ```
 
-This simple policy takes the `test-deployment` namespace and all resources contained within it and deploys it to all member clusters in the fleet with the given `environment` label. If all clusters are desired, you can remove the `affinity` term entirely.
+This simple policy takes the `prod-deployment` namespace and all resources contained within it and deploys it to all member clusters in the fleet with the given `environment` label. If all clusters are desired, you can remove the `affinity` term entirely.
 
 ### `PickFixed` placement policy
 

articles/service-bus-messaging/service-bus-messages-payloads.md

@@ -67,16 +67,16 @@ When you use the legacy SBMP protocol, those objects are then serialized with th
 
 [!INCLUDE [service-bus-amqp-support-retirement](../../includes/service-bus-amqp-support-retirement.md)]
 
-While this hidden serialization magic is convenient, applications should take explicit control of object serialization and turn their object graphs into streams before including them into a message, and do the reverse on the receiver side. This yields interoperable results. While AMQP has a powerful binary encoding model, it's tied to the AMQP messaging ecosystem, and HTTP clients will have trouble decoding such payloads. 
+While this hidden serialization magic is convenient, applications should take explicit control of object serialization and turn their object graphs into streams before including them into a message, and do the reverse on the receiver side. This yields interoperable results. While AMQP has a powerful binary encoding model, it's tied to the AMQP messaging ecosystem, and HTTP clients will have trouble decoding such payloads.
 
-The .NET Standard and Java API variants only accept byte arrays, which means that the application must handle object serialization control. 
+The .NET Standard and Java API variants only accept byte arrays, which means that the application must handle object serialization control.
 
-If the payload of a message can't be deserialized, then it's recommended to [dead-letter the message](./service-bus-dead-letter-queues.md?source=recommendations#application-level-dead-lettering).
+When handling object deserialization from the message payload, developers should take into consideration that messages may arrive from multiple sources using different serialization methods. This can also happen when evolving a single application, where old versions may continue to run alongside newer versions. In these cases, it is recommended to have additional deserialization methods to try if the first attempt at deserialization fails. One library that supports this is [NServiceBus](https://docs.particular.net/nservicebus/serialization/#specifying-additional-deserializers). If all deserialization methods fail, then it's recommended to [dead-letter the message](./service-bus-dead-letter-queues.md?source=recommendations#application-level-dead-lettering).
 
 ## Next steps
 
 To learn more about Service Bus messaging, see the following topics:
 
 * [Service Bus queues, topics, and subscriptions](service-bus-queues-topics-subscriptions.md)
 * [Get started with Service Bus queues](service-bus-dotnet-get-started-with-queues.md)
-* [How to use Service Bus topics and subscriptions](service-bus-dotnet-how-to-use-topics-subscriptions.md)
+* [How to use Service Bus topics and subscriptions](service-bus-dotnet-how-to-use-topics-subscriptions.md)