Using delay plug-ins causes consumers to lose messages

[kaixinbaba]

In my business, first of all, there is an ordinary consumer A (non - delayed exchange). However, due to the nature of the business itself, after receiving these messages, they will be immediately sent to a delayed queue (the currently set delay time is 1 minute). Then another consumer B will consume these delayed messages and execute the actual business logic.

The current situation is as follows:

Consumer A received 14 messages and successfully sent these 14 messages to the delayed queue (both can be proved by ELK logs).
Consumer B only received 5 messages and there is no error log either.
The observed phenomenon is that a part of the 14 messages were sent in the same second (only accurate to the second). After deduplication according to this timestamp, only 5 messages are left. I don't know whether this number is a coincidence or really related to time.
Reproduction steps
Unfortunately, this problem cannot be reproduced locally.

Expected behavior
So I'm here to ask for help. May I ask:

Does the delayed queue plug - in itself have such a mechanism that can lead to this kind of problem? (I personally don't think so, but I'm here to ask for confirmation.)
How to troubleshoot such a problem? Does RMQ itself have tools to see how many pieces of data the server itself has received? (Interface console or command - line tool)
Additional context
Since I am a developer in China. In order to express the meaning accurately, I will paste the original Chinese text here below.

我的业务中，首先有一个普通的消费者A（非延迟 exchange），但是因为业务本身的缘故，在收到这些消息后，会立马发送到一个延迟队列中（目前设置的延迟时间是 1 分钟），再通过另一个消费者B去消费这些延迟后的消息，并且执行实际的业务逻辑。
现在的情况是：

消费者 A 收到了 14 条消息，并且成功将这 14 条消息发送至延迟队列（均有 ELK 日志可以证明）
消费者 B 却只收到了 5 条消息，并且也没有报错的日志
观察到的现象，14 条消息中有一部分消息发送的时间是在同一秒（只是精确到秒），按照这个时间戳去重后，就剩下了 5 条，这个数字不知道是巧合还是确实和时间有关
所以来求助，请问：

延迟队列插件本身有这样的机制会导致这种问题吗？（我个人认为是不会，但是来求助确认下）
这样的问题如何排查，RMQ 本身有工具可以看到服务端本身接收到多少条数据吗（界面控制台或者是命令行工具）

[kaixinbaba]

Version info:

1. RabbitMQ 3.8.4
2. Erlang 23.2.1
3. rabbitmq-delayed-message-exchange 3.8.0

[michaelklishin]

RabbitMQ 3.8.x has reached EOL years ago.

This plugin cannot affect consumers. Publishers in AMQP 0-9-1 are entirely unaware of consumers. All this plugin does is republishing message.

Perhaps your consumers cannot handle the deliveries and fail, thus closing the connection or channel.

See logs and take a traffic capture to see what is really send on the wire. Firehose can also potentially be useful, it must be enabled on the node that accepts published messages routed to this exchange.