此文件专门查缺补漏。
此处主要是针对的master和slave role这两种角色，当前sentinel已有的记录在 master或slave role的sentinelRedisInstance中的flags字段暴露的role信息与 从对应的redis instance的info反馈的role信息吻合以及不吻合的情况的分类 列举如下，可能每个大的分类下的具体分类里还会有不完整的情况，但是大的分类 就基本只有四种。
-
当前sentinelRedisInstance的role是master，相应的redis instance info报告的role也是master
这是当前sentinel没有任何异议的情况
-
当前sentinelRedisInstance的role是master，相应的redis instance info报告的role却是slave
如果role是master，但是report的却是slave，并且mstime() - ri->role_reported_time > (ri->down_after_period+SENTINEL_INFO_PERIOD*2),则会标记当前sentinelRedisInstance为+sdown, 如果经历了大多数的同意，则可能会走入failover的流程, 移交出自己的master地位。之前提过了。
-
当前sentinelRedisInstance的role是slave，相应的redis instance info报告的role却是master
-
如果是在failover in progress的情况以及当前sentinelRedisInstance就是failover的promoted_slave, 则此处正符合failover wait promotion的逻辑，failover进入下一个阶段, 此时当前sentinel有义务尽快将 此变更通知other sentinel,以避免被other sentinel按照下一种情况纠正处理了，这也就是下一种情况纠正 处理前的等待时间是SENTINEL_PUBLISH_PERIOD*4这样一个与publish period挂钩的时间的原因。
-
如果此处一个slave被提升为master，但又并不是我们期待的变更，则此处等待一定时间之后，会采取 convert-to-slave纠正这个不吻合的情况, 注意此处不会有任何other sentinel的参与也会直接执行， 因为此时当前sentinel持有的master config会被认为是一个稳定的config，会被直接生效, 即假设大家的配置都与 这个配置一致。
-
-
当前sentinelRedisInstance的role是slave，相应的redis instance info报告的role也是slave
如果role是slave，报告的role也是slave, 这种情况下还是可能有异议。
如果当前slave sentinelRedisInstance的master处于look sane的状态，但是slave instance的info报告的master host以及port 与记录的master并不匹配，则此时纠正当前slave instance slave of我们记录中的master instance。
此处只是在一处汇总了上述所有情况，关于每种情况的细节，之前都已经提过了
简单的回答，不会。ri->flags关于这两个状态的改变只有如下情况。
-
在创建三种role的sentinelRedisInstance时，会给flags赋值成不同的状态，即三种不同的role。
-
会在SentinelResetMaster时强制保证reset masterd的对象是SRI_MASTER状态, 其实不出意外的话，应该是没必要的.