Enhancement to help EP Merge metrics

[dfitchett]

Requesting Team

Employee Experience

Related product/initiative

svc-bip-api

Problem/Need

In an effort to clear up some of the failure metrics in EP Merge, we would like to request the addition of the contentions/special_issue_types endpoint along with one or more rabbitMQ endpoints to interact with it.

Why?

Currently, a majority of our EP Merge job failures are related to trying to move contentions that have a special issue code that is deactivated, however this should not be considered a failed job, but rather the job should be considered aborted due to ineligibility. Implementing this logic will give us a more accurate representation of failed jobs.

Acceptance criteria

From the EP Merge app we expect to have a request queue established in RabbitMQ to send requests to svc-bip-api which will return a response.

Ideally, the request would contain an array of special issue codes to look up and verify if they are still active, and the response would contain an array of booleans indicating the state (active or deactive).

Priority

Priority is medium.

Target timeline

This is for a new feature of the EP Merge App, but any work on that will be blocked without having this endpoint.

Context and documentation

See the related ticket about investigating the availability of this endpoint.

• https://github.com/department-of-veterans-affairs/abd-vro/issues/3206

AC: Deploy to prod and communicate with EE that this has been done.

[meganhicks]

I will get this into the next Sprint. Is this okay?

[meganhicks]

https://confluence.devops.va.gov/display/VAExternal/Subdomain%3A+Contention+Events

[dfitchett]

@meganhicks this endpoint is not part of Contention Events, but rather it is an already available endpoint in the BIP claims API, and it just needs the corresponding endpoint in the svc-bip-api.

[nelsestu]

Created a draft PR with a healthy head start to all the necessary elements: https://github.com/department-of-veterans-affairs/abd-vro/pull/3280

[BerniXiongA6]

Hi @nelsestu would you be able to update the comments with current progress? Will this complete or will it need to carry over to next sprint?

[dfitchett]

After a discussion with @nelsestu it was decided that this new endpoint would be a passthrough endpoint just like the other endpoints. "Passthrough" meaning that when a request is made to the svc-bip-api via RabbitMQ, the requests is made to the downstream BIP claims API, and the response is then passed to the response queue in the reply-to header of the original RabbitMQ message.

The original ticket was modified to strikethrough the original suggestion.

[nelsestu]

Having met with the team to discuss the dead letter queue deployment, we agreed to decouple this ticket from Sprint A's deployment. Derek confirms that there is no urgency from an EE perspective. Based on where #3213 is at the present moment, EE use of the endpoint is unblocked and can begin at any time. As such, the dead letter queue deployment is happening as I type this, and it will continue to production as verification allows for. As we may have guessed, the failing github check which continues to delay 3213, is in fact a RabbitMQ queue creation error. is anyone surprised by this? not likely.