异步接口很快返回 bulk_uuid，但查询状态时所有 operation 长期为 open。请求已被接收不等于已经执行；消息可能没有入队、对应 Consumer 未运行、持续失败重试，或状态写回事务被阻塞。

先固定复现条件和影响范围

保存 bulk_uuid、路由、提交条数、创建时间与一个 operation_key。统计 open、complete_recoverable、complete 和 rejected 数量，不记录请求中的客户或认证敏感数据。

SELECT uuid,description,operation_count,start_time FROM magento_bulk ORDER BY start_time DESC LIMIT 10;
SELECT bulk_uuid,status,topic_name,operation_key,error_code,result_message
FROM magento_operation WHERE bulk_uuid='BULK-UUID' ORDER BY id;
php bin/magento queue:consumers:list
php bin/magento queue:consumers:start async.operations.all --max-messages=50 -vvv
php bin/magento queue:consumers:start product_action_attribute.update --max-messages=50 -vvv

根据证据分支定位

没有 magento_operation 行，检查请求路由和提交事务；有 open 且队列深度增长，检查 Consumer；转为 recoverable 或 rejected，则读取脱敏错误信息并修业务数据。DB 队列与 RabbitMQ 环境使用的检查方式不同，先确认 env.php 的实际连接。

修复时保留回滚路径

恢复正确 Consumer 和 Supervisor 配置，并对失败操作按业务幂等性决定重试。不要直接把状态 UPDATE 为 complete，也不要删除 open 行掩盖积压；大批量按可承受条数拆分，并给 API 调用方提供状态与失败明细。

上线验收

提交包含成功、可恢复失败和永久失败的小批次，状态应最终收敛且成功实体已保存。重启 Consumer 后消息不能丢失或重复产生业务副作用，积压曲线应持续下降。

生产环境操作前的检查

处理“Magento 2 异步批量 API 一直停在 open”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近一次发布。所有 SQL 默认先执行 SELECT；任何写操作、目录清理或配置切换都应确认影响范围、保留备份并准备回滚。多节点环境要核对各节点代码版本、app/etc/env.php 配置摘要与流量分布。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费或订单的改动，先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。准备一个正常对象与一个异常对象对照；若旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层需要保存的证据通过标准
入口层 URL、状态码、请求 ID、节点 路由和协议一致
应用层 异常堆栈、模块、作用域 无新异常且可重复
数据层 主键、时间、关联行数 关系完整且无重复副作用
业务层 正常、失败、重试路径 最终结果一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器和目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。