一次纯线上接口异常的排查过程

背景

线上接口发生异常，在测试环境及本地环境均正常返回无法复现异常问题。

技术栈

前端 umi + antd，后端 egg + egg-sequelize，主要排查方向在后端。

开始排查

开始排查异常，异常接口返回无详细错误信息。返回错误信息只有一个简单的错误提示 其他异常，该提示是接口异常默认的提示。

EXCEPTION_MSG: '其他异常'

但是接口异常正常会传入具体的异常信息，到前端却成了默认值，可见此处传入了一个undefined。

try {
  ...code
} catch (e) {
  return ctx.EXCEPTION(e && e.toString())
}

经过排查是其中一个逻辑处理中的 try catch 异常时没有在reject中返回对应的错误内容，导致最后返回给前端时变成了默认值。

return new Promise(async(resolve, reject) => {
  try {
   ...code
  } catch (error) {
-   reject()
+   reject(error)
  }
})

经过处理后错误异常信息出现了，提示正则表达式无效，根据错误提示的源头找到对应的业务代码函数，但在此函数中却没有使用正则相关的代码。

SyntaxError: Invalid regular expression: /^:(?<name>[a-z_][0-9a-z_]*)(?:\)|,|$|\s|::|;|])/: Invalid group
  at injectReplacements (/opt/web/node/xxx/node_modules/sequelize/lib/utils/sql.js:120:37)
  at Sequelize.query (/opt/web/node/xxx/node_modules/sequelize/lib/sequelize.js:282:13)
  at Promise (/opt/web/node/xxx/app/service/sentry/xxx.js:628:45)
  at new Promise (<anonymous>)
  ...

因为该函数中存在调用其他的业务功能，通过日志打印的方式排查出发生异常的代码如下，这里就是一个sql查询，因需要查询字段的顺序与返回的列表一致，用到了 replacements，因其他环境也是正常的，排除此语法问题。

await this.model.query(sql, {
  replacements: { name: sortList },
  type: QueryTypes.SELECT
})

回到上面抛出异常的调用关系，调用业务代码之后依次调用了 Sequelize.query，injectReplacements，发生了异常，则问题出在 injectReplacements。但查阅本地 Sequelize.query 源码并没有出现 injectReplacements 调用，源码针对 replacements 配置只会有以下处理，这就有些奇怪了。

if (options.replacements) {
  if (Array.isArray(options.replacements)) {
    sql = Utils.format([sql].concat(options.replacements), this.options.dialect);
  } else {
    sql = Utils.formatNamedParameters(sql, options.replacements, this.options.dialect);
  }
}

既然本地代码找不到，那么就去服务器上的源码查找看看，果然不出所料，服务器上的源码居然不一致。

if (options.replacements) {
  sql = injectReplacements(sql, this.dialect, options.replacements);
}

injectReplacements 函数中最终调用到了以下的正则，就是本文最开始的异常提示内容，提示正则无效。

const match = remainingString.match(/^:(?<name>[a-z_][0-9a-z_]*)(?:\)|,|$|\s|::|;|])/i);
const replacementName = (_d = match == null ? void 0 : match.groups) == null ? void 0 : _d.name;
if (!replacementName) {
  continue;
}

然后分别查看了两个环境依赖包 sequelize 的版本号，本地环境是 sequelize@6.16.1，而线上环境的实际安装版本是 sequelize@6.21.3。

"_from": "sequelize@^6.0.0",
"_id": "sequelize@6.21.3",

既然是版本的问题，那么统一版本号看看本地是否可以复现，因为这个依赖不是直接依赖包，无法直接锁定版本，所以先删除本地 node_modules 及 package-lock.json 后重新安装，最终安装完成的版本号和服务器一致了，都是sequelize@6.21.3，但是此时本地运行正常。🤷‍♀️

现在依赖版本都一致，运行结果却不同。那么查询两端运行版本区别，经过查询，本地node版本号v12.22.1，服务器v8.17.0。结果不言而喻了，因为运行系统的版本不一致导致正则识别错误，在网上也查到其他人也有同样的问题，node在某些版本下对正则识别的问题。通过在远端服务器和本地服务器分别执行同样的代码，服务器node版本为v8.17.0执行发生异常。

但是为什么会出现这样的问题呢，之前不是一直好好的吗？原因是被依赖的sequelize没有锁死版本号，从项目开始到现在sequelize一直在不断升级。经过查询官方github，因为有sql注入的问题，从6.19.2版本开始对此问题进行了修复，导致正则问题在较老的node版本中无法识别，发生异常。github issue地址：github.com/sequelize/s…

解决

可以用两种方式解决此问题，因为发生异常的依赖包并不是直接的依赖包，无法直接写死对应的版本号，那么可以修改package-lock文件中依赖包的版本号，但此方式并不稳定，在后期安装还是会被覆盖。第二种方式就是升级node版本，因为公司内部服务器的项目较多，需要有一定的测试回归覆盖才行，有一定的风险性和成本。

最后

本文到此结束，通过本次排查线上问题得出两个结论。接口异常没有返回具体的错误信息，代码问题后续需注意，提高异常发生时的解决效率；排查问题时在保证一份代码的同时也要保证不同环境的系统版本以及依赖版本的一致性，对于依赖包的版本尽可能锁定版本号，避免自动升级带来未知的风险。