@onlineapps/mq-client-core 1.0.43 → 1.0.45

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@onlineapps/mq-client-core",
-  "version": "1.0.43",
+  "version": "1.0.45",
   "description": "Core MQ client library for RabbitMQ - shared by infrastructure services and connectors",
   "main": "src/index.js",
   "scripts": {

package/src/config/queueConfig.js

@@ -207,14 +207,20 @@ module.exports = {
 
   /**
    * Monitoring infrastructure queue configurations
-   * These are dedicated queues for Monitoring service (separate from delivery queues)
+   * These are dedicated queues for Monitoring service (infrastructure service)
+   * 
+   * CRITICAL: Monitoring is an infrastructure service, monitoring queues are infrastructure queues!
+   * All services (both infrastructure and business) publish monitoring events here.
    */
   monitoring: {
     /**
-     * monitoring.workflow.completed - Completed workflows for monitoring
-     * Business services publish here for observability (separate from workflow.completed for delivery)
+     * monitoring.workflow - Unified workflow lifecycle monitoring
+     * Delivery Dispatcher publishes 'completed'/'failed' events after processing workflow.completed/workflow.failed
+     * Business services publish 'progress' events during workflow step processing
+     * Message format includes event_type: 'completed' | 'failed' | 'progress'
+     * Includes full cookbook and context snapshots for trace storage
      */
-    'workflow.completed': {
+    'workflow': {
       durable: true,
       arguments: {
         'x-message-ttl': 300000,      // 5 minutes TTL
@@ -223,36 +229,19 @@ module.exports = {
     },
 
     /**
-     * monitoring.workflow.failed - Failed workflows for monitoring
-     * Business services publish here for observability (separate from workflow.failed for delivery)
+     * monitoring.services - Service lifecycle events monitoring
+     * Registry publishes service lifecycle events (registered, validation.completed, version.changed, status.changed)
+     * InfrastructureHealthTracker publishes service status changes
+     * Message format includes event_type: 'service.registered' | 'service.validation.completed' | 
+     *   'service.version.changed' | 'service.deregistered' | 'service.status.changed'
+     * NOTE: Heartbeats are NOT published here (too frequent, every 10s)
+     * NOTE: Healthcheck messages go to infrastructure.health.events exchange
      */
-    'workflow.failed': {
+    'services': {
       durable: true,
       arguments: {
-        'x-message-ttl': 300000,      // 5 minutes TTL
-        'x-max-length': 10000
-      }
-    },
-
-    /**
-     * monitoring.registry.events - Registry events for monitoring
-     */
-    'registry.events': {
-      durable: true,
-      arguments: {
-        'x-message-ttl': 60000,       // 1 minute TTL
-        'x-max-length': 5000
-      }
-    },
-
-    /**
-     * monitoring.service.heartbeats - Service heartbeats for monitoring
-     */
-    'service.heartbeats': {
-      durable: true,
-      arguments: {
-        'x-message-ttl': 120000,      // 2 minutes TTL
-        'x-max-length': 10000
+        'x-message-ttl': 600000,      // 10 minutes TTL (longer for service tracking)
+        'x-max-length': 20000
       }
     }
   },
@@ -262,27 +251,28 @@ module.exports = {
    */
   registry: {
     /**
-     * registry.register - Registration requests
+     * registry.register - Main queue for ALL service communication with Registry
+     * 
+     * CRITICAL: This is the ONLY queue used for service-to-Registry communication.
+     * Registry listener processes different message types based on msg.type:
+     * - type: 'register' - Service registration requests
+     * - type: 'heartbeat' - Periodic health check messages (sent every 10s)
+     * - type: 'apiDescription' - API specification responses
+     * 
+     * Architecture rationale:
+     * - Single consumer on registry.register handles all message types
+     * - Simplifies queue management (one queue instead of multiple)
+     * - Registry can process messages in order and maintain state consistency
+     * - All business services send both registration AND heartbeats to this queue
      */
     register: {
       durable: true,
       arguments: {
-        'x-message-ttl': 60000,       // 1 minute TTL
+        'x-message-ttl': 60000,       // 1 minute TTL (for registration requests)
         'x-max-length': 1000
       }
     },
 
-    /**
-     * registry.heartbeats - Service heartbeats
-     */
-    heartbeats: {
-      durable: true,
-      arguments: {
-        'x-message-ttl': 120000,       // 2 minutes TTL
-        'x-max-length': 5000
-      }
-    },
-
     /**
      * registry.changes - Registry event fanout exchange
      * (This is an exchange, not a queue, but included for reference)