关键词：
IBV_WC_WR_FLUSH_ERR、CQ、QP、wr_id、RDMA CM、STAR
S｜Situation：连接成功，却在第一轮 READY 阶段报错
完成 READY/ACK 初步改造后，我在主机先插入约 5 万条数据，再启动从机进行 AOF 同步。主机只打印了"master listening"和"master connection established"；从机打印"slave connection established""SEND type=3, length=0"，随后出现：Work Request Flushed Error(5), vendor_err=0x0, opcode=128, byte_len=0。这个日志特别容易被误读为"READY 消息发送失败"。但结合代码，SEND type=3 的打印位置在 rdma_send_block() 成功等待 SEND CQE 之后，说明它更可能是在随后等待 DATA 的接收完成时，拿到了一个失败的 RECV 完成事件。
T｜Task：区分根因错误与被清理的后续 WR
IBV_WC_WR_FLUSH_ERR 的核心含义是某个工作请求由于 QP 错误或相关状态变化而被冲刷完成。它本身经常不是第一现场。要查清问题，需要同时回答：哪个 WR 失败、QP 为什么进入错误状态、对端是否主动断开、是否发生 RNR 或接收缓冲区未准备好、是否有其他线程在操作同一个 CQ。
A｜Action：回到源码逐项还原时序
代码检查发现两个具体风险。第一，从机在 slave_rdma_start() 已经调用一次 rdma_post_recv()，而进入 rdma_recv_file() 后又调用一次；两次都指向同一个 rbuffer。第二，主机只在 rdma_send_file() 中才首次提交接收 READY 的 RECV，而从机进入文件接收函数后就可能立刻发送 READY。也就是说，主机打印"连接建立"并不意味着它已经为第一条 READY 准备了接收槽位。
我将建议的修复顺序调整为：主机在 rdma_accept() 前提交首个 RECV，删除 rdma_send_file() 中重复提交首个 RECV 的代码；从机删除连接初始化阶段的 RECV，仅在 rdma_recv_file() 中提交接收请求。这样可以消除代码中明确存在的接收槽位重复和首条控制消息竞争风险。不过，不能仅凭 flush 错误就断言唯一根因一定是缺少首个 RECV，还必须检查最早的 WC 错误和 RDMA CM 事件。
进一步的诊断日志应包括：
fprintf(stderr,
"WC: status=%s(%d), opcode=%d, wr_id=%llu, vendor_err=%u
",
ibv_wc_status_str(wc.status), wc.status,
wc.opcode, (unsigned long long)wc.wr_id,
wc.vendor_err);原代码中 SEND 和 RECV 使用同一个 CQ，且 wr_id 都被设置成 cm 指针。对于更复杂的并发场景，这不利于区分完成事件。应当给 SEND/RECV 或不同槽位分配可识别的 wr_id，并由统一 CQ 事件分发逻辑处理，避免一个等待 SEND 的函数意外取走 RECV 完成事件。日志中 opcode=128 在常见 verbs 实现中对应 RECV 完成类型，但最好使用常量 IBV_WC_RECV 判断，不应把数字硬编码进业务逻辑。
此外，还要监听并记录 RDMA_CM_EVENT_DISCONNECTED 等事件，检查 ibv_post_send()、ibv_post_recv() 的返回值，确认失败后不继续使用错误状态的 QP。当前 rdma_poll_wc() 无限自旋且没有超时，断连时可能造成线程卡死；rdma_wait_cm_event() 的部分调用也没有完整检查返回值，容易掩盖真正的连接问题。
R｜Result：形成了按"首个错误"追踪的排障方法
这一轮并没有从现有日志直接证明底层根因，但已经明确了两处源码级风险，并建立了更可靠的诊断顺序：先确定最早的失败事件，再关联 WR、CQ、QP 和 CM 生命周期，最后才判断是否属于接收队列不足或对端提前关闭。对于线上系统，这种方法比反复增加 sleep() 更有价值，因为 flush error 往往只是错误链条的末端表现。
面试延伸：3 道八股与项目问题
1. IBV_WC_WR_FLUSH_ERR 是否说明当前 WR 的 SGE 长度写错了？
答： 不能这样判断。Flush 表示 WR 因 QP 错误等原因被清理，不直接指明最初错误。SGE 越界、远端断连、RNR 重试耗尽或其他错误都需要结合更早的 WC、CM 事件和设备日志分析。
2. SEND 和 RECV 共用一个 CQ 有什么风险？
答： 共用 CQ 本身合法，但多个函数或线程不能假定下一个 CQE 一定属于自己等待的操作。若随意轮询并丢弃不匹配的 opcode，会造成完成事件丢失。应通过 wr_id 标识请求，统一分发或使用独立 CQ，并保证 CQ 只有受控的消费者。
3. 为什么 RDMA 连接建立成功后仍可能立即失败？
答： RDMA CM 的 ESTABLISHED 说明连接协商完成，不代表应用层 RECV WR、文件句柄和协议状态全部就绪。对端提前发送、缓冲区不足、错误清理、异步断连等仍可能导致 QP 错误。需要在应用层增加 READY、状态检查和超时机制。