Currently messages that are sent from EP Merge to any VRO service that is down will remain in the queue until that service comes online and consumes the messages from the queue. EP Merge will always reject the responses in those cases if they have reached the max latency set for the clients in the hoppy_service.py which is 30s.
Possible Effects:
None of the GET endpoints would have any adverse effects, but there can be issues if the requests are modifying downstream data. For all of the cases below, actions could be completed in any order even though the merge job might have been completed unsuccessfully:
cancelling - shouldn't have any issue, temp station of jurisdiction might have been reverted later
adding or updating contentions - contentions could be duplicated on existing claims (both pending and ep400), special issues removed, temp station of jurisdiction, but in ANY order
setting the temp_station_of_jurisdiction - could overwrite original and remove special issue in any order
adding claim note - claim note would be added for every request made that sat in the queue until BGS was back up (default is 3 requests)
Temporary solution
Request that VRO apply queue level TTL to 0 seconds for all BGS/BIP queues used by EP Merge.
Best / Long term solution
Update lib-hoppy to send requests to queue with per message TTL option set to client's max-latency value.
Acceptance Criteria
[x] Update lib-hoppy #3180
[x] Update EP Merge to use updated lib-hoppy #3186
Summary
Currently messages that are sent from EP Merge to any VRO service that is down will remain in the queue until that service comes online and consumes the messages from the queue. EP Merge will always reject the responses in those cases if they have reached the max latency set for the clients in the
hoppy_service.pywhich is 30s.Possible Effects:
None of the
GETendpoints would have any adverse effects, but there can be issues if the requests are modifying downstream data. For all of the cases below, actions could be completed in any order even though the merge job might have been completed unsuccessfully:Temporary solution
Request that VRO apply queue level TTL to 0 seconds for all BGS/BIP queues used by EP Merge.
Best / Long term solution
Update
lib-hoppyto send requests to queue with per message TTL option set to client's max-latency value.Acceptance Criteria
sandbox