应用后台闲置约5分钟后GraphQL订阅失效问题求助

针对你遇到的使用subscriptions-transport-ws时，应用后台5分钟后订阅停止工作但WebSocket连接未断开的问题，这里有几个可行的排查和解决方向：

• 浏览器后台节流导致心跳失效
  即使你设置了inactivityTimeout: 300000，浏览器在后台标签页会限制定时器执行频率，可能导致subscriptions-transport-ws内置的心跳机制无法正常触发。可以手动添加自定义心跳，主动维持连接活跃：

  const client = new SubscriptionClient(
    `wss://localhost/graphql`,
    {
      reconnect: true,
      lazy: true,
      timeout: 300000,
      inactivityTimeout: 300000,
      connectionCallback: (error) => {
        if (error) {
          console.error('WS CONNECTION_CB ERROR::: ', error)
        }
        return true
      }
    }
  )
  
  // 自定义心跳：每3分钟发送一次ping
  let heartbeatTimer;
  client.onConnected(() => {
    heartbeatTimer = setInterval(() => {
      client.send({ type: 'ping' });
    }, 180000);
  });
  
  client.onDisconnected(() => {
    clearInterval(heartbeatTimer);
  });
  

• 检查lazy模式的影响
  你配置了lazy: true，该模式下客户端会在没有活跃订阅时自动断开连接。虽然WebSocket日志显示连接未断，但后台状态下订阅可能被标记为非活跃，导致消息停止推送。尝试将lazy改为false，强制保持WebSocket连接：

  {
    reconnect: true,
    lazy: false, // 修改此处
    timeout: 300000,
    inactivityTimeout: 300000,
    // ...其他配置
  }
  

• 确认服务器端超时配置
  客户端的超时设置无法覆盖服务器端的限制，比如Nginx的proxy_read_timeout、GraphQL服务器的WebSocket连接超时等。需要确保服务器端的超时时间设置大于5分钟，避免服务器主动切断连接。

• 监听页面可见性事件，重新激活订阅
  部分浏览器会在后台标签限制WebSocket消息接收，可以通过监听visibilitychange事件，在页面恢复可见时重新启动订阅：

  // 假设你的订阅逻辑封装在restartSubscription函数中
  function restartSubscription() {
    // 取消现有订阅并重新发起
    // ...你的订阅重启逻辑
  }
  
  document.addEventListener('visibilitychange', () => {
    if (document.visibilityState === 'visible') {
      restartSubscription();
    }
  });
  

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