Merge pull request #299035 from bishal41/2504-known-issues

2504 known issues fixes

Author: Court72

articles/iot-operations/troubleshoot/known-issues.md

@@ -47,66 +47,6 @@ If you deploy Azure IoT Operations in GitHub Codespaces, shutting down and resta
 
 Currently, there's no workaround for the issue. If you need a cluster that supports shutting down and restarting, choose one of the options in [Prepare your Azure Arc-enabled Kubernetes cluster](../deploy-iot-ops/howto-prepare-cluster.md).
 
-### Helm package enters a stuck state during update
-
----
-
-Issue ID: 9928
-
----
-
-Log signature: `"Message: Update failed for this resource, as there is a conflicting operation in progress. Please try after sometime."`
-
----
-
-When you update Azure IoT Operations, the Helm package might enter a stuck state, preventing any helm install or upgrade operations from proceeding. This scenario results in the error message `Update failed for this resource, as there is a conflicting operation in progress. Please try after sometime.`, which blocks further updates.
-
-To work around this issue, follow these steps:
-
-1. Identify the stuck components by running the following command:
-
-   ```sh
-   helm list -n azure-iot-operations --pending
-   ```
-
-    In the output, look for the release name of components, `<component-release-name>`, which have a status of `pending-upgrade` or `pending-install`. This issue might affect the following components:
-
-      - `-adr`
-      - `-akri`
-      - `-connectors`
-      - `-mqttbroker`
-      - `-dataflows`
-      - `-schemaregistry`
-
-1. Using the `<component-release-name>` from step 1, retrieve the revision history of the stuck release. You need to run the following command for **each component from step 1**. For example, if components `-adr` and `-mqttbroker` are stuck, you run the following command twice, once for each component:
-
-   ```sh
-   helm history <component-release-name> -n azure-iot-operations
-   ```
-
-    Make sure to replace `<component-release-name>` with the release name of the components that are stuck. In the output, look for the last revision that has a status of `Deployed` or `Superseded` and note the revision number.
-
-1. Using the **revision number from step 2**, roll back the Helm release to the last successful revision. You need to run the following command for each component, `<component-release-name>`, and its revision number, `<revision-number>`, from steps 1 and 2.
-
-    ```sh
-    helm rollback <component-release-name> <revision-number> -n azure-iot-operations
-    ```
-  
-    > [!IMPORTANT]
-    > You need to repeat steps 2 and 3 for each component that is stuck. You reattempt the upgrade only after all components are rolled back to the last successful revision.
-
-1. After the rollback of each component is complete, reattempt the upgrade using the following command:
-
-   ```sh
-   az iot ops update
-   ```
-
-    If you receive a message stating `Nothing to upgrade or upgrade complete`, force the upgrade by appending:
-
-    ```sh
-    az iot ops upgrade ....... --release-train stable 
-    ```
-
 ## MQTT broker issues
 
 This section lists current known issues for the MQTT broker.
@@ -238,46 +178,6 @@ To work around this issue, you can either:
 
 This section lists current known issues for the connector for media and the connector for ONVIF.
 
-### Cleanup of unused media-connector resources
-
----
-
-Issue ID: 2142
-
----
-
-Log signature: N/A
-
----
-
-If you delete all the `Microsoft.Media` asset endpoint profiles, the deployment for media processing isn't deleted.
-
-To work around this issue, run the following command using the full name of your media connector deployment:
-
-```bash
-kubectl delete deployment aio-opc-media-... -n azure-iot-operations
-```
-
-### Cleanup of unused onvif-connector resources
-
----
-
-Issue ID: 3322
-
----
-
-Log signature: N/A
-
----
-
-If you delete all the `Microsoft.Onvif` asset endpoint profiles, the deployment for media processing isn't deleted.
-
-To work around this issue, run the following command using the full name of your ONVIF connector deployment:
-
-```bash
-kubectl delete deployment aio-opc-onvif-... -n azure-iot-operations
-```
-
 ### AssetType CRD removal process doesn't complete
 
 ---
@@ -336,20 +236,6 @@ Log signature: N/A
 
 X.509 authentication for custom Kafka endpoints isn't currently supported.
 
-### Data points aren't validated against a schema
-
----
-
-Issue ID: 8794
-
----
-
-Log signature: N/A
-
----
-
-When you create a data flow, you can specify a schema in the source configuration. However, deserializing and validating messages using a schema isn't supported yet. Specifying a schema in the source configuration only allows the operations experience to display the list of data points, but the data points aren't validated against the schema.
-
 ### Connection failures with Azure Event Grid
 
 ---
@@ -366,38 +252,6 @@ When you connect multiple IoT Operations instances to the same Event Grid MQTT n
 
 To work around this issue, add randomness to the data flow names in your deployment templates.
 
-### Data flow errors after a network disruption
-
----
-
-Issue ID: 8953
-
----
-
-Log signature: N/A
-
----
-
-When the network connection is disrupted, data flows might encounter errors sending messages because of a mismatched producer ID.
-
-To work around this issue, restart your data flow pods.
-
-### Disconnections from Kafka endpoints
-
----
-
-Issue ID: 9289
-
----
-
-Log signature: N/A
-
----
-
-If you use control characters in Kafka headers, you might encounter disconnections. Control characters in Kafka headers such as `0x01`, `0x02`, `0x03`, `0x04` are UTF-8 compliant but the IoT Operations MQTT broker rejects them. This issue happens during the data flow process when Kafka headers are converted to MQTT properties using a UTF-8 parser. Packets with control characters might be treated as invalid and rejected by the broker and lead to data flow failures.
-
-To work around this issue, avoid using control characters in Kafka headers.
-
 ### Data flow deployment doesn't complete
 
 ---