Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `src/api/integrations/event/rabbitmq/rabbitmq.controller.ts:116` </location>
<code_context>
+      return;
+    }
+
+    this.connectionStatus = this.reconnectAttempts > 0 ? 'reconnecting' : 'connecting';
+
     return new Promise<void>((resolve, reject) => {
</code_context>

<issue_to_address>
Connection status is set before async connect logic, which may lead to race conditions.

This approach can cause incorrect status if multiple connections are initiated simultaneously. Recommend updating connectionStatus only after the connection outcome, or preventing concurrent connect attempts.
</issue_to_address>

### Comment 2
<location> `src/api/integrations/event/rabbitmq/rabbitmq.controller.ts:51` </location>
<code_context>
+  private async closeConnection(): Promise<void> {
+    try {
+      if (this.amqpChannel) {
+        await new Promise<void>((resolve) => {
+          this.amqpChannel?.close((err) => {
+            if (err) {
+              this.logger.warn(`Error closing channel: ${err.message}`);
+            }
+            resolve();
+          });
+        });
</code_context>

<issue_to_address>
Callback-based close methods are wrapped in Promises but do not handle errors robustly.

Currently, errors during channel closure are only logged, not propagated. Please reject the Promise on error so upstream code can handle failures, or clearly document this behavior.

Suggested implementation:

```typescript
        await new Promise<void>((resolve, reject) => {
          this.amqpChannel?.close((err) => {
            if (err) {
              this.logger.warn(`Error closing channel: ${err.message}`);
              reject(err);
              return;
            }
            resolve();
          });
        });

```

```typescript
        await new Promise<void>((resolve, reject) => {
          this.amqpConnection?.close((err) => {
            if (err) {
              this.logger.warn(`Error closing connection: ${err.message}`);
              reject(err);
              return;
            }

```
</issue_to_address>

### Comment 3
<location> `src/api/integrations/event/rabbitmq/rabbitmq.controller.ts:90` </location>
<code_context>
+    return this.connectionStatus === 'connected' && this.amqpChannel !== null && this.amqpConnection !== null;
+  }
+
+  public async forceReconnect(): Promise<void> {
+    this.logger.info('Force reconnect requested');
+    
</code_context>

<issue_to_address>
forceReconnect resets reconnectAttempts and calls connect, but may conflict with ongoing reconnection logic.

Consider adding checks or canceling any active reconnection attempts within forceReconnect to prevent race conditions with isReconnecting and reconnectTimer.
</issue_to_address>

### Comment 4
<location> `src/api/integrations/event/rabbitmq/rabbitmq.controller.ts:211` </location>
<code_context>
-          this.amqpChannel = channel;
-          this.reconnectAttempts = 0; // Reset reconnect attempts on successful connection
-          this.isReconnecting = false;
+          }, (exchangeError) => {
+            if (exchangeError) {
+              this.connectionStatus = 'disconnected';
</code_context>

<issue_to_address>
Callback error handling for assertExchange may not propagate errors to the connection logic.

Ensure that, if assertExchange fails, all resources are properly cleaned up or the connection is closed to avoid leaving the system in a partially initialized state.
</issue_to_address>

### Comment 5
<location> `src/api/integrations/event/rabbitmq/rabbitmq.controller.ts:292` </location>
<code_context>
     );

-    setTimeout(async () => {
+    this.reconnectTimer = setTimeout(async () => {
+      if (this.isShuttingDown) {
+        return;
</code_context>

<issue_to_address>
Reconnect timer is cleared in finally block, but may be overwritten by concurrent calls.

Concurrent calls to scheduleReconnect can overwrite reconnectTimer, causing lost references and possible memory leaks. Use a safer approach to manage timer instances.
</issue_to_address>

### Comment 6
<location> `src/api/integrations/event/rabbitmq/rabbitmq.controller.ts:459` </location>
<code_context>
-          await this.amqpChannel.bindQueue(queueName, exchangeName, event);
+        await this.amqpChannel.bindQueue(queueName, exchangeName, routingKey);
+
+        const published = await new Promise<boolean>((resolve) => {
+          const success = this.amqpChannel.publish(
+            exchangeName,
</code_context>

<issue_to_address>
publishMessage uses a callback for publish, but may not handle all error scenarios.

If the channel closes or the connection drops, the callback may not trigger, causing the promise to hang. Add error handling or a timeout to ensure the promise resolves in all scenarios.
</issue_to_address>