Gremlin JavaScript客户端Socket断连时未抛出异常如何解决

问题根因 #

• 3.5.2版本Node.js gremlin客户端存在逻辑缺陷：底层Socket感知到连接关闭事件时，不会遍历清理当前队列中所有等待响应的请求，导致执行await t.next()生成的Promise始终处于pending状态，调用链路永久阻塞；未被回收的请求上下文会持续占用内存，引发资源泄漏。
• 客户端本身可通过内部日志事件识别Socket关闭状态，但该事件未和上层请求的状态流转逻辑打通，不会给等待中的请求抛出对应异常。

可行解决方案 #

方案1：无版本升级的手动补丁 #

不需要升级依赖，通过扩展客户端实例逻辑，主动监听连接关闭事件，批量终止pending状态的请求：

const gremlin = require('gremlin');
const { v4: uuidv4 } = require('uuid'); // 可选，用于手动生成请求ID

// 初始化客户端
const client = new gremlin.driver.Client('ws://your-gremlin-endpoint/gremlin', {
  traversalSource: 'g',
  // 保留原有业务配置
});

// 缓存原始请求提交方法
const originalSubmit = client.submit.bind(client);
// 维护pending请求映射：key为请求ID，value为对应Promise的reject方法
const pendingRequests = new Map();

// 重写submit方法，接管全链路请求生命周期
client.submit = function (bytecode, opts = {}) {
  // 若内部拿不到请求ID，可手动生成ID透传
  const requestId = opts.requestId || uuidv4();
  opts.requestId = requestId;

  const originPromise = originalSubmit(bytecode, opts);
  return new Promise((resolve, reject) => {
    pendingRequests.set(requestId, reject);
    originPromise
      .then(resolve)
      .catch(reject)
      .finally(() => {
        // 请求正常结束后移除记录
        pendingRequests.delete(requestId);
      });
  });
};

// 统一处理连接异常，批量reject所有等待中的请求
const handleConnectionTerminate = () => {
  const connClosedError = new Error('Gremlin connection closed before request got response');
  connClosedError.name = 'GremlinConnectionClosedError';
  for (const [reqId, reject] of pendingRequests.entries()) {
    reject(connClosedError);
    pendingRequests.delete(reqId);
  }
};

// 给连接实例注册所有异常断开相关的事件监听
const conn = client._connection;
conn.on('close', handleConnectionTerminate);
conn.on('error', handleConnectionTerminate);
conn.on('disconnect', handleConnectionTerminate);

// 客户端销毁时主动移除事件监听，避免监听器泄漏
const originalClose = client.close.bind(client);
client.close = async function () {
  conn.off('close', handleConnectionTerminate);
  conn.off('error', handleConnectionTerminate);
  conn.off('disconnect', handleConnectionTerminate);
  return originalClose();
};

提示：如果业务使用连接池模式，需要遍历连接池内的所有连接实例注册上述监听逻辑，不要只给单个连接注册事件。

方案2：增加超时兜底防护 #

作为补丁逻辑的补充防护层，给所有gremlin请求增加超时控制，即使出现遗漏的异常场景，也不会出现无限等待：

/**
 * 给Promise增加超时控制
 * @param {Promise} promise 原始请求Promise
 * @param {number} timeoutMs 超时时间，单位毫秒
 * @returns 
 */
function withRequestTimeout(promise, timeoutMs = 30000) {
  return Promise.race([
    promise,
    new Promise((_, reject) => {
      const timer = setTimeout(() => {
        clearTimeout(timer);
        reject(new Error(`Gremlin request timed out after ${timeoutMs}ms`));
      }, timeoutMs);
    })
  ]);
}

// 调用示例
const traversalResult = await withRequestTimeout(t.next(), 30000);

注意：超时阈值需要根据业务实际查询的耗时分布调整，避免正常的慢查询被误截断。

方案3：升级到修复版本 #

该缺陷已经在官方后续版本中合入修复逻辑，升级gremlin依赖到包含对应修复的正式版本后，即可原生支持连接断开时自动清理pending请求、抛出异常，不需要额外编写补丁逻辑。升级后需要验证连接断开场景下异常是否正常抛出，确认请求队列清理逻辑符合预期。

落地注意事项 #

• 不要仅依赖超时逻辑做防护：如果不在连接断开时主动清理pending请求，超时触发前的等待周期内，请求上下文依然会持续占用内存，高并发场景下仍会引发内存泄漏。
• 补丁逻辑需要覆盖全量连接异常场景：包括服务端主动断连、网络中断、客户端主动销毁连接、连接鉴权失败等，避免遗漏场景导致请求挂起。
• 所有手动注册的事件监听器，都需要在客户端/连接实例销毁时主动移除，避免监听器本身造成内存泄漏。

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