Queue Services

Purpose

These repositories appear to implement background or message-driven processing for domain workflows. They should be documented as part of the platform architecture, even if not every developer needs to run them every day.

Shared runtime facts

• config file pattern: .env.sample
• transport: RabbitMQ
• broker port: 5672
• main local command: pnpm run start:dev

Common env groups

• PORT
• DB_*
• RABBITMQ_*
• vendor credentials such as telnet, SSH, ZTE, APIM, and reset URLs depending on the worker

Current queue repositories

Repository	Queue or queues	Confirmed caller from code	Notes
mvp3-caution-report-queue-service	intt_caution_report_queue	not yet traced to a producer in current pass	background CR processing
mvp3-changedp-queue-service	intt_alu_queue, intt_zte_queue, intt_fiberhome_queue, intt_huawei_queue	mvp3-gsb-service	vendor-specific changedp work
mvp3-ctt-queue-service	intt_ctt_queue	mvp3-ticket-service, mvp3-ngoss-service, mvp3-nocpro-service, mvp3-tmf-service, mvp6-tass-queue-service, mvp6-vital-queue-service	dead-letter key intt_ctt_dlq configured
mvp3-gsb-queue-service	intt_gsb_queue	mvp3-gsb-service	general GSB async work
mvp3-kci-queue-service	intt_kci_queue	mvp3-ticket-service, mvp3-ngoss-service, mvp3-nocpro-service	unlike most workers, also opens an HTTP port
mvp6-tass-queue-service	intt_tass_queue	delay queue eventually routes into it	dead-letter key intt_tass_dlq configured
mvp6-vital-queue-service	intt_vital_queue	mvp6-vital-service	dead-letter key intt_vital_dlq configured

Important note about repo quality

Several queue repositories have copy-pasted README or package.json metadata. For now:

• trust folder names first
• treat README descriptions as hints, not truth
• confirm actual queue bindings, consumers, and publishers from source code before writing deep flow docs

Trigger rules confirmed from code

Trigger source	Queue action confirmed from code
GSB service device operations	publishes to device-specific queues for ALU, ZTE, Fiberhome, or Huawei
GSB service general async actions	sends RPC-style patterns like gsb-create-dp, gsb-delete-dp, gsb-sync-speed, gsb-untag-vlan-400 to intt_gsb_queue
Ticket service KCI flows	emits KCI events such as create-kci, update-kci, closure-kci, and troubleshoot-kci
Ticket service CTT or NTT updates	emits or sends tmf-update-ctt-list to intt_ctt_queue
NGOSS or NOCPro updates	emits create-kci and sends tmf-update-ctt-list
Vital service	emits vital-send-ctt and vital-update-ctt-activity to intt_vital_queue
TASS queue service	emits taas-enrich-tm-category to intt_tass_tm_category_delay_queue

Team clarification

• most queue triggers come from API calls
• external dependencies are generally reached through development or staging endpoints
• DLQ handling relies on automatic retry after the configured number of attempts

Dead-letter and delay behavior confirmed from code

Queue	Behavior confirmed from code
intt_ctt_queue	dead-letters to intt_ctt_dlq
intt_vital_queue	dead-letters to intt_vital_dlq
intt_tass_queue	dead-letters to intt_tass_dlq
intt_tass_tm_category_delay_queue	waits 120000 ms then dead-letters into intt_tass_queue

Still needs team confirmation

• which user-facing actions are the intended trigger for every queue in production
• who owns replay from each DLQ
• whether caution-report queue has an additional producer outside the repos reviewed here

When developers need these locally

Run queue services when you are working on:

• async workflow completion
• event-driven integration bugs
• delayed status updates
• background processing and retry logic
• external system handoff flows

Local testing

• run worker: pnpm run start:dev
• confirm RabbitMQ connection is healthy
• publish or trigger one domain action from its owning API
• watch logs for consumer receipt, processing, and retry behavior