go-mysql/client Execute方法传错误binlog位置时阻塞原因咨询

核心原因是库的响应包解析逻辑存在分支遗漏，没有覆盖MySQL服务端返回错误的特殊时序：

• SHOW BINLOG EVENTS属于MySQL的特殊语句，传入非法binlog offset触发错误时，服务端不会在命令响应的第一时间直接返回ERR包，而是先下发结果集的列定义元数据包，再在后续拉取行数据的阶段返回ERR错误包。
• go-mysql/client的Execute方法原有逻辑采用固定流程处理响应：
  1. 先读取首个响应包，如果是ERR包直接返回错误，如果是OK包直接返回执行成功
  2. 如果判定是结果集响应，就先读取所有列定义包，之后进入循环持续读取行数据包，直到读取到EOF标记包才退出循环返回结果
• 上述逻辑完全没有处理「列定义读取完成后、行读取阶段收到ERR包」的场景：当收到服务端在半路返回的ERR包时，代码会将其错误识别为普通行数据包，解析失败后既不抛出错误终止流程，也不退出读取循环，会一直等待后续永远不会到达的数据包，最终表现为调用永久阻塞。
• MySQL控制台执行同类语句能立刻拿到错误，是因为官方客户端在结果集读取的全流程都做了ERR包检测，任意阶段收到错误都会立刻终止读取返回，不会出现死等。

临时处理方案 #

• 升级go-mysql依赖到已修复该问题的新版本，新版本已经补全了结果集读取全链路的ERR包判断逻辑，遇到这类场景会正常返回错误不会阻塞。
• 若暂时无法升级依赖，执行这类语句时需要绑定带超时的上下文，通过context.WithTimeout设置合理的执行超时时间，避免协程永久泄漏。

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