We can confirm. In one of our environments we have the same issue. It started 24+ hours after the update. After rebooting the server it all came up. We have a DAG setup, so restarting moves the database copies (unless you do it descently manual > same behaviour). The copy states was healthy/mounted on the passive/active hosting server with minor queus, like 1-2 and then 0. However the passive copy gets the status of FAILED when rebooting the server where the active copy came from.
Kinda worrisome if you come into the situation of multiple servers in a DAG and all have failusers on the replication service. Maybe wise for consistency to temporary block auto failover on databases -or- set it to strict?