SonarQube分支仪表盘仍显示已修复的Blocker Bug，求排查

以下是可能导致SonarQube分支仪表盘仍显示已修复Blocker的原因及排查步骤：

• 分支分析任务未正确执行
  检查CI/CD流水线的SonarQube分析任务日志，确认协作分支的分析是否触发，且任务执行成功：有没有拉取到最新的修复代码，过程中有没有报错（比如依赖缺失、权限问题）。如果任务没跑或者失败，分支数据停留在旧版本，自然会显示旧问题。

• SonarQube分支数据未更新或缓存问题
  登录SonarQube后台，进入项目的「任务」页面，查看协作分支的最近分析记录。如果存在失败的任务，重新触发分析；如果任务成功但仪表盘没更新，尝试手动刷新页面，或者在SonarQube后台触发分支的重新分析。部分版本的SonarQube可能存在索引延迟，等待几分钟再查看。

• 修复逻辑未符合SonarQube规则判定标准
  虽然本地分析无问题，但服务器端的规则可能对修复逻辑有更严格的判定。比如你的工具方法是否确保ExecutorService一定会被关闭：

  • 工具方法内部是否有未捕获的异常，导致关闭代码没执行？
  • 工具方法是否在某些条件下会提前返回，跳过关闭步骤？
  • 有没有用shutdown()还是shutdownNow()？SonarQube的规则是否要求必须确保资源释放，比如即使shutdown()后还要等待终止？
    可以把修复后的代码片段（比如finally块调用工具方法的部分）贴出来，对照SonarQube的规则细节验证。

• 分支配置不匹配
  确认SonarQube中配置的分支名称和你推送的协作分支名称完全一致（注意大小写、前缀后缀，比如feature/xxx和feature_xxx是不同分支）。如果CI里配置的SonarQube分支参数有误，会导致分析数据关联到错误的分支，当前分支仪表盘还是旧数据。

• 分析器/规则版本不一致
  检查本地使用的sonar-scanner版本和SonarQube服务器版本是否兼容，以及项目的规则集是否和服务器端一致。如果本地用的是较新的分析器，修复逻辑被新版本规则认可，但服务器端用的旧版本规则没识别到修复，就会出现本地正常、服务器异常的情况。

内容的提问来源于stack exchange，提问作者Sameh