search

department-of-veterans-affairs / abd-vro

To get Veterans benefits in minutes, VRO software uses health evidence data to help fast track disability claims.
Other
17 stars 6 forks source link

RabbitMQ request/response agreement strategy integrated into the codebase #2176

Open tejans24 opened 8 months ago

tejans24 commented 8 months ago

User Story

As a partner team engineer, I want VRO to have a consistently defined and documented RabbitMQ request/response agreement strategy integrated into the codebase using tools like AsyncAPI or XSD, so that I can easily develop my application with reliable and current specifications for VRO services.

Dependencies Understanding the current request/response agreements in place for VRO services. Knowledge of AsyncAPI or XSD for specification integration.

Acceptance Criteria

The RabbitMQ request and response formats (where applicable) are defined and documented directly within the codebase using AsyncAPI or XSD. Standards for defining RabbitMQ queue and exchange declarations are documented within the codebase. Tickets are created to apply this strategy to VRO's existing services, including acceptance criteria for documenting the request/response format for each service within the code.

dianagriffin commented 7 months ago

From @dfitchett in slack:

I took a stab at defining the VRO rabbitMQ strategy. Here's a :thread: for any input and suggestions.

dfitchett commented 7 months ago

Follow on tickets:

Note there is no ticket for BIP, because these standards are based on the current implementation.

dianagriffin commented 7 months ago

From @CorySohrakoffUSDS in slack:

One more reliability thing I wanted to add for consideration - from briefly looking, I believe the consumer is set to auto acknowledge messages. If there are multiple consumers, and one dies when it dequeues a message intended for another consumer, that message may be lost (if not requeued before the consumer died). An alternative would be to use manual acknowledgement with a delivery ack timeout so that the message is requeued if it is not ack'd within a specified amount of time. (Also relevant is delayed requeuing, but it may not be necessary unless we see a high message load.)

meganhicks commented 1 month ago

The team agrees this is still needed but they do not agree on the approach. They think this should live in the code base itself and not on a wiki. 1. Find a tool and write the spec in code. 2. Apply this to all microservices. tool options- AsyncAPI, XSD