The secondary replica does not know the role / status of that
When trying to failover to the secondary, the status of the primary is not known:
it finds the current primary replica but not the primary replica status.
When failing over from the primary it does find this information.
When you select the properties of the replica with the question mark on the secondary replica:
Whereas on the primary replica all roles and their sync states are known.
Executing this query returns multiple lines on the primary, but only the one for the secondary on the secondary replica's.
select * from sys.dm_hadr_availability_replica_states;
This behaviour would be reversed after failover.
When looking at the query that gets executed when opening the properties of the unknown replica on the secondary replica, the
sys.dm_hadr_availability_replica_states dmv is also used with a
left join in a much bigger query.
An interesting part here is the
ISNULL(arstates.operational_state, 6) AS [OperationalState],
Meaning if the replica is not present in that dmv, such as when executing on the secondary, return
6 as the
This state is not explicitly noted in the documentation on the dmv:
operational_state tinyint Current operational state of the replica,
0 = Pending failover
1 = Pending
2 = Online
3 = Offline
4 = Failed
5 = Failed, no quorum
NULL = Replica is not local.
For more information, see Roles and Operational States, later in this
'Unkown' state is also not noted in the documentation.
In this case
6 is used when the role is not known.
It does not always appear to be
6, when refreshing the availability replica's on the secondary:
the query used sets the unknown replica's role status to 3:
ISNULL(arstates.role, 3) AS [Role],
Which is offline on the dmv's documentation.
And the connected state column will be
ISNULL(arstates.connected_state, 2) AS [ConnectionState],
Which is also not noted in the documentation:
0 : Disconnected. ...
1 : Connected. ...