kffl/bunny-rest-proxy

HTTP message broker built on top of RabbitMQ :rabbit::incoming_envelope:

bunny-rest-proxy's Issues

the problem with the dead message policy

hello, I ran into such a problem that when specifying a dead message policy, I get this error(I saw a message in the documentation that the library is not fully ready yet, was this meant):

/app/build/subscriber/retry-manager.js:18
2023-09-11 17:57:48 this.logger.warn(Exceeded the maximum number of delivery attempts for the message ID: ${msg.properties.messageId}, ${this.deadLetterPolicy.descripeBehavior} message);
2023-09-11 17:57:48 ^
2023-09-11 17:57:48
2023-09-11 17:57:48 TypeError: Unable to read undefined properties (reading 'descripeBehavior')

Could this be a problem related to incorrect configuration file configuration? Here is my configuration.yml

---

publishers:

• queueName: json-queue
  Content Type: json
• Queue name: my_queue
  Content Type: json
  • queueName: dead
    contentType: json
• Queue name: binary queue
  Content type: binary
  consumers:
• queueName: json-queue
• Queue name: my_queue
• Queue name: binary queue
• Queue name: dead
• subscribers:
• queueName: json queue
  purpose: http://host.docker.internal:8001/subscribe
  preliminary selection: 2
  Retreat strategy: constant
  attempts: 2
  Repeated delay: 1000
• queueName: json queue
  purpose: http://host.docker.internal:8002/subscribe
  preliminary selection: 2
  Retreat strategy: constant
  attempts: 2
  Repeated delay: 1000
• queueName: json queue
  purpose: http://host.docker.internal:8003/subscribe
  preliminary selection: 2
  Retreat strategy: constant
  attempts: 2
  Repeated delay: 1000
  deadLetterPolicy: dql
  deadLetterQueueName: dead

Prometheus metrics

In an effort to improve BRP's observability in production environments, runtime metrics could be collected and exposed for Prometheus to scrape. These may include:

• a default set of Node.js metrics collected via prom-client
• incoming request latency histograms per publisher/consumer
• PUSH message delivery latency histograms per subscriber target
• publisher/subscriber/consumer counters by success/error status

Publisher latency histogram collects metric value before the actual AMQP operation is completed

It seems that a missing await statement causes the publisher latency timer being stopped before the actual AMQP operation is completed, which results in reported publisher latency metrics being in the tens of microseconds.

Logging improvements

The following improvements could be made to logging:

• Include additional logger calls at the highest verbosity level (trace) for easier debugging.
• Prefix logs with unified context info specifying the component (publisher/subscriber/consumer with its corresponding queue name) in which the logging was triggered and providing message-specific information (message ID, correlation ID).