docs/release_notes/v1.16.6.md
This update includes bug fixes:
The Dapr sidecar injector was incorrectly logging "succeeded injection" and recording metrics for non-Dapr applications (pods without the dapr.io/enabled: "true" annotation). Although the injector correctly skipped injection for these pods, the false success logs and metrics made it difficult to monitor actual sidecar injection activity and distinguish between real injections and non-Dapr pod processing.
Users inspecting sidecar injector logs and metrics saw misleading "successful injection" entries for applications that did not have Dapr enabled, making it difficult to monitor true injection success rates and debug injection issues.
The injector treated "successfully processed the admission request" as "successfully injected the sidecar". When processing non-Dapr pods, getPodPatchOperations() correctly returned an empty patch with no error, but the code still logged success and recorded metrics even though no actual injection occurred.
The injector now only logs success and records metrics when patch operations are generated (len(patchOps) > 0), ensuring we only report successful injections when an actual sidecar injection happens.
On initialization, daprd will print an error log stating "Error attempting to migrate reminders to scheduler: statestore reminders is not ready".
The error log is misleading as it suggests a failure in migrating reminders, while in reality, it indicates that the state store is not yet ready during the initialization phase. This can cause confusion for users monitoring logs.
Programming error resulting in this log being printed at an inappropriate time during initialization.
The error log no longer prints during successful initialization.
By default when running in Kubernetes, Dapr had a check where if the process was running with a UID or GID which was not 65532, the program would exit with an error.
This causes issues for users running in Openshift/OKD environments where the platform assigns random UIDs to pods for security reasons.
The check was too strict, as it did not account for scenarios where only the root user (UID 0) should be allowed, while other UIDs should be blocked.
Only check for root (UID 0) and allow all other UIDs to run Dapr.