Merge pull request #303411 from dominicbetts/release-aio-2507-known-issues

AIO 2507: Update known issues

Author: ttorble

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

@@ -129,52 +129,41 @@ Log signature: N/A
 
 When you add a new asset with a new asset endpoint profile to the OPC UA broker and trigger a reconfiguration, the deployment of the `opc.tcp` pods changes to accommodate the new secret mounts for username and password. If the new mount fails for some reason, the pod doesn't restart and therefore the old flow for the correctly configured assets stops as well.
 
-### Data spike every 2.5 hours with some OPC UA simulators
+### An OPC UA server modeled as a device can only have one inbound endpoint of type "Microsoft.OpcUa"
 
 ---
 
-Issue ID: 6513
+Issue ID: 2411
 
 ---
 
-Log signature: Increased message volume every 2.5 hours
+`2025-07-24T13:29:30.280Z aio-opc-supervisor-85b8c78df5-26tn5 - Maintaining the new asset test-opcua-asset | - | 1 is skipped because the endpoint profile test-opcua.opcplc-e2e-anon-000000 is not present`
 
 ---
 
-Data values spike every 2.5 hours when using particular OPC UA simulators causing CPU and memory spikes. This issue isn't seen with OPC PLC simulator used in the quickstarts. No data is lost, but you can see an increase in the volume of data published from the server to the MQTT broker.
+When you create an OPC UA device, you can only have one inbound endpoint of type `Microsoft.OpcUa`. Currently, any other endpoints aren't used.
 
-### No message schema generated if selected nodes in a dataset reference the same complex data type definition
+Workaround: Create multiple devices with a single endpoint each if you want to use namespace assets.
 
----
+An OPC UA namespaced asset can only have a single dataset. Currently, any other datasets aren't used.
 
-Issue ID: 7369
+Workaround: Create multiple namespace assets each with a single dataset.
 
----
 
-Log signature: `An item with the same key has already been added. Key: <element name of the data type>`
+
+### Data spike every 2.5 hours with some OPC UA simulators
 
 ---
 
-No message schema is generated if selected nodes in a dataset reference the same complex data type definition (a UDT of type struct or enum).
+Issue ID: 6513
 
-If you select data points (node IDs) for a dataset that share non-OPC UA namespace complex type definitions (struct or enum), then the JSON schema isn't generated. The default open schema is shown when you create a data flow instead. For example, if the data set contains three values of a data type, then whether it works or not is shown in the following table. You can substitute `int` for any OPC UA built in type or primitive type such as `string`, `double`, `float`, or `long`:
+---
 
-| Type of Value 1 | Type of Value 2 | Type of Value 3 | Successfully generates schema |
-|-----------------|-----------------|-----------------|-----------------|
-| `int` | `int` | `int` | Yes |
-| `int` | `int` | `int` | Yes |
-| `int` | `int` | `struct A` | Yes |
-| `int` | `enum A` | `struct A` | Yes |
-| `enum A` | `enum B` | `enum C` | Yes |
-| `struct A` | `struct B` | `struct C` | Yes |
-| `int` | `struct A` | `struct A` | No |
-| `int` | `enum A` | `enum A` | No |
+Log signature: Increased message volume every 2.5 hours
 
-To work around this issue, you can either:
+---
 
-- Split the dataset across two or more assets.
-- Manually upload a schema.
-- Use the default nonschema experience in the data flow designer.
+Data values spike every 2.5 hours when using particular OPC UA simulators causing CPU and memory spikes. This issue isn't seen with OPC PLC simulator used in the quickstarts. No data is lost, but you can see an increase in the volume of data published from the server to the MQTT broker.
 
 ## Connector for media and connector for ONVIF issues
 
@@ -192,7 +181,7 @@ Log signature: `"Error HelmUninstallUnknown: Helm encountered an error while att
 
 ---
 
-Sometimes, when you attempt to uninstall Azure IoT Operations from the cluster, the system can get to a state where CRD removal job is stuck in pending state and that blocks the cleanup of Azure IoT Operations.
+Sometimes, when you attempt to uninstall Azure IoT Operations from the cluster, the system reaches a state where CRD removal job is stuck in pending state, which blocks the cleanup of Azure IoT Operations.
 
 To work around this issue, complete the following steps to manually delete the CRD and finish the uninstall:
 
@@ -204,115 +193,98 @@ To work around this issue, complete the following steps to manually delete the C
 
 1. Uninstall Helm release without running the hook: `helm uninstall aio-<id>-connectors -n azure-iot-operations --no-hooks`
 
-## Asset discovery with Akri services issues
-
-This section lists current known issues for asset discovery with Akri services.
-
-### Asset discovery doesn't work for one hour after upgrade
+### Media and ONVIF devices with an underscore character in the endpoint name are ignored
 
 ---
 
-Issue ID: 0407
+Issue ID: 5712
 
 ---
 
 Log signature: N/A
 
 ---
 
-When you upgrade the Akri services, you might experience some loss of messages and assets for an hour after the upgrade.
-
-To workaround this issue, wait for an hour after the upgrade and run the asset detection scenario again.
-
-## Data flows issues
+If you create a media or ONVIF device with an endpoint name that contains an underscore ("_") character, the connector for media ignores the device.
 
-This section lists current known issues for data flows.
+To work around this issue, use a hyphen ("-") instead of an underscore in the endpoint name.
 
-### Data flow resources aren't visible in the operations experience web UI
+### Media connector doesn't use the path in destination configuration
 
 ---
 
-Issue ID: 8724
+Issue ID: 6797
 
 ---
 
 Log signature: N/A
 
 ---
 
-Data flow custom resources created in your cluster using Kubernetes aren't visible in the operations experience web UI. This result is expected because [managing Azure IoT Operations components using Kubernetes is in preview](../deploy-iot-ops/howto-manage-update-uninstall.md#manage-components-using-kubernetes-deployment-manifests-preview), and synchronizing resources from the edge to the cloud isn't currently supported.
+Media assets with a task type of "snapshot-to-fs" or "clip-to-fs" don't honor the path in the destination configuration. Instead, they use the "Additional configuration" path field.
 
-There's currently no workaround for this issue.
-
-### Connection failures with Azure Event Grid
+### Media connector ignores MQTT topic setting in asset
 
 ---
 
-Issue ID: 8891
+Issue ID: 6780
 
 ---
 
 Log signature: N/A
 
 ---
 
-When you connect multiple IoT Operations instances to the same Event Grid MQTT namespace, connection failures might occur due to client ID conflicts. Client IDs are currently derived from data flow resource names, and when using infrastructure as code patterns for deployment, the generated client IDs might be identical.
-
-To work around this issue, add randomness to the data flow names in your deployment templates.
+The media connector ignores the MQTT destination topic setting in the asset. Instead, it uses the default topic: `/azure-iot-operations/data/<asset-name>/snapshot-to-mqtt`.
 
-### Data flow deployment doesn't complete
+### Media connector inbound endpoint addresses aren't fully validated
 
 ---
 
-Issue ID: 9411
+Issue ID: 2679
 
 ---
 
-Log signature:
-
-`"Dataflow pod had error: Bad pod condition: Pod 'aio-dataflow-operator-0' container 'aio-dataflow-operator' stuck in a bad state due to 'CrashLoopBackOff'"`
-
-`"Failed to create webhook cert resources: Failed to update ApiError: Internal error occurred: failed calling webhook "webhook.cert-manager.io" [...]"`
+Log signature: N/A
 
 ---
 
-When you create a new data flow, it might not finish deployment. The cause is that the `cert-manager` wasn't ready or running.
+In the public preview release, the media connector accepts device inbound endpoint addresses with the following schemes: `async`, `cache`, `concat`, `concatf`, `crypto`, `data`, `fd`, `ffrtmpcrypt`, `ffrtmphttp`, `file`, `ftp`, `gopher`, `gophers`, `hls`, `http`, `httpproxy`, `https`, `mmsh`, `mmst`, `pipe`, `rtmp`, `rtmpe`, `rtmps`, `rtmpt`, `rtmpte`, `rtmpts`, `rtp`, `srtp`, `subfile`, `tcp`, `tls`, `udp`, `udplite`, `unix`, `ipfx`, `ipns`.
 
-To work around this issue, use the following steps to manually delete the data flow operator pod to clear the crash status:
+This enables input data from multiple source types. However, because the output configuration is based on the `streamConfiguration`, the possibilities for using data from these sources are limited.
 
-1. Run `kubectl get pods -n azure-iot-operations`.
-   In the output, Verify _aio-dataflow-operator-0_ is only data flow operator pod running.
+## Data flows issues
 
-1. Run `kubectl logs --namespace azure-iot-operations aio-dataflow-operator-0` to check the logs for the data flow operator pod.
+This section lists current known issues for data flows.
 
-   In the output, check for the final log entry:
+### Data flow resources aren't visible in the operations experience web UI
 
-   `Dataflow pod had error: Bad pod condition: Pod 'aio-dataflow-operator-0' container 'aio-dataflow-operator' stuck in a bad state due to 'CrashLoopBackOff'`
+---
 
-1. Run the _kubectl logs_ command again with the `--previous` option.
+Issue ID: 8724
 
-   `kubectl logs --namespace azure-iot-operations --previous aio-dataflow-operator-0`
+---
 
-   In the output, check for the final log entry:
+Log signature: N/A
 
-   `Failed to create webhook cert resources: Failed to update ApiError: Internal error occurred: failed calling webhook "webhook.cert-manager.io" [...]`.
-Issue ID:2382
-   If you see both log entries from the two _kubectl log_ commands, the cert-manager wasn't ready or running.
+---
 
-1. Run `kubectl delete pod aio-dataflow-operator-0 -n azure-iot-operations` to delete the data flow operator pod. Deleting the pod clears the crash status and restarts the pod.
+Data flow custom resources created in your cluster using Kubernetes aren't visible in the operations experience web UI. This result is expected because [managing Azure IoT Operations components using Kubernetes is in preview](../deploy-iot-ops/howto-manage-update-uninstall.md#manage-components-using-kubernetes-deployment-manifests-preview), and synchronizing resources from the edge to the cloud isn't currently supported.
 
-1. Wait for the operator pod to restart and deploy the data flow.
+There's currently no workaround for this issue.
 
-### Data flows error metrics
+### Connection failures with Azure Event Grid
 
 ---
 
-Issue ID: 2382
+Issue ID: 8891
 
 ---
 
 Log signature: N/A
 
 ---
 
-Data flows marks message retries and reconnects as errors, and as a result data flows might look unhealthy. This behavior is only seen in previous versions of data flows. Review the logs to determine if the data flow is healthy.
+When you connect multiple IoT Operations instances to the same Event Grid MQTT namespace, connection failures might occur due to client ID conflicts. Client IDs are currently derived from data flow resource names, and when using infrastructure as code patterns for deployment, the generated client IDs might be identical.
+
+To work around this issue, add randomness to the data flow names in your deployment templates.