WEBRTC场景下离线时撤销写入操作的实现方案问询

我之前处理过类似的WebRTC场景问题，用户离线发起通话后关闭应用，后续在线时服务器可能把旧的异常请求推给接收方，确实会造成困扰。结合你的需求，我整理了一套完整的实现方案，涵盖写入确认、超时撤销的全流程：

核心思路拆解 #

你的需求本质是保证通话请求的最终一致性：

• 发起请求时同时做好本地记录和服务器写入
• 确认服务器写入成功后清理本地状态
• 超时未确认则主动撤销请求，避免后续异常推送

具体实现步骤（附代码示例） #

1. 向服务器写入通话请求（兼顾离线场景） #

首先，每个通话请求需要生成唯一ID用于追踪，同时本地缓存请求状态，防止离线时丢失上下文：

// 生成唯一请求ID，用浏览器原生的crypto API更可靠
function generateRequestId() {
  return crypto.randomUUID();
}

// 发起通话请求的核心函数
async function initiateCall(callData) {
  const requestId = generateRequestId();
  const callRequest = {
    ...callData,
    requestId,
    status: 'pending', // 标记为待确认状态
    createdAt: Date.now()
  };

  try {
    // 先把请求存到本地localStorage，防止离线时应用关闭丢失
    await saveCallRequestToLocal(requestId, callRequest);
    // 尝试向服务器发送写入请求
    await fetch('/api/call-requests', {
      method: 'POST',
      body: JSON.stringify(callRequest),
      headers: { 'Content-Type': 'application/json' }
    });
    // 启动后续的确认监听和超时检查
    startConfirmationWorkflow(requestId);
  } catch (err) {
    // 离线或网络错误时，直接启动超时流程，后续在线再处理
    startConfirmationWorkflow(requestId);
    console.warn('发起通话请求失败（可能离线），将继续追踪状态:', err);
  }
}

// 本地存储辅助函数
function saveCallRequestToLocal(requestId, data) {
  localStorage.setItem(`call_req_${requestId}`, JSON.stringify(data));
}

2. 监听成功事件并验证元数据 #

服务器写入成功后，建议用WebSocket实时接收确认事件（轮询效率低），然后验证服务器返回的元数据是否匹配本地记录：

// 初始化WebSocket监听服务器确认事件
function setupCallSignalingSocket() {
  const ws = new WebSocket('wss://your-signaling-server.com/ws');
  
  ws.onmessage = (event) => {
    const msg = JSON.parse(event.data);
    if (msg.type === 'call_request_confirmed') {
      const { requestId, serverMeta } = msg;
      // 从本地取出对应请求，验证一致性
      const localReq = JSON.parse(localStorage.getItem(`call_req_${requestId}`));
      
      if (localReq && serverMeta.status === 'success' && serverMeta.requestId === requestId) {
        // 确认写入成功，清理本地状态和超时定时器
        clearTimeout(window[`call_timeout_${requestId}`]);
        localStorage.removeItem(`call_req_${requestId}`);
        console.log('通话请求已成功同步到服务器');
      }
    }
  };
}

// 页面加载时初始化WebSocket
document.addEventListener('DOMContentLoaded', setupCallSignalingSocket);

3. 超时检测与撤销操作 #

设置合理的超时时间（比如30秒，可根据网络情况调整），超时未收到确认则主动调用服务器撤销接口，同时处理离线时的撤销延迟：

function startConfirmationWorkflow(requestId) {
  const TIMEOUT_MS = 30000; // 30秒超时阈值
  
  const timeoutId = setTimeout(async () => {
    const localReq = JSON.parse(localStorage.getItem(`call_req_${requestId}`));
    if (!localReq || localReq.status !== 'pending') return;

    try {
      // 调用服务器撤销接口
      await fetch(`/api/call-requests/${requestId}`, { method: 'DELETE' });
      console.log(`通话请求[${requestId}]超时，已成功撤销`);
      localStorage.removeItem(`call_req_${requestId}`);
    } catch (err) {
      // 离线时无法撤销，标记为待撤销，下次启动时重试
      localReq.status = 'needs_cancel';
      saveCallRequestToLocal(requestId, localReq);
      console.warn(`超时撤销失败（离线），请求[${requestId}]将在下次在线时重试`);
    }
  }, TIMEOUT_MS);

  // 把超时ID存在全局，方便后续成功时清理
  window[`call_timeout_${requestId}`] = timeoutId;
}

// 应用启动时检查本地遗留的待处理请求
function checkPendingRequestsOnStartup() {
  Object.keys(localStorage).forEach(key => {
    if (key.startsWith('call_req_')) {
      const requestId = key.replace('call_req_', '');
      const localReq = JSON.parse(localStorage.getItem(key));
      
      if (localReq.status === 'pending') {
        // 重新启动超时检查
        startConfirmationWorkflow(requestId);
      } else if (localReq.status === 'needs_cancel') {
        // 尝试撤销遗留的待撤销请求
        fetch(`/api/call-requests/${requestId}`, { method: 'DELETE' })
          .then(() => localStorage.removeItem(key))
          .catch(() => console.log(`请求[${requestId}]撤销失败，下次启动再试`));
      }
    }
  });
}

// 启动时执行检查
checkPendingRequestsOnStartup();

关键注意事项 #

• 唯一ID的必要性：每个请求必须有唯一标识，确保撤销和确认的准确性，避免误操作其他请求。
• 服务器端配合：服务器需要实现三个核心接口：写入通话请求、返回确认事件、处理撤销请求，并且撤销后要停止向接收方推送该请求。
• 超时时间调整：如果是弱网环境，可以适当延长超时时间（比如60秒），避免误判。
• 本地存储选择：如果需要存储更多数据，建议用IndexedDB替代localStorage，容量更大且支持异步操作。

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