Potential stockout notifications may get lost when stock management service goes down

When processing a stock event, it was discovered that the logic to determine if there is a stockout and to notify the corresponding stock card "editors" was performing rather slowly, and it was affecting requisition single approve. A short-term solution was to make the notification logic asynchronous, so the stock event processing would not wait for the notification code to finish. This asynchronous logic introduces a queue

This async code introduced a potential minor bug where stock card editors would not get notified of a stockout, since Spring would create a queue to process these potential notifications. This bug would occur if all of the following are true:

• the stock management service is processing the notifications slowly enough to not be able to clear out the queue

• an administrator stops the service before the queue is cleared out

• any of the notification calls not yet processed would find a stockout and need to notify the stock card editors

A solution to this bug should be found in this ticket. Some possible solutions:

• Store unprocessed queue items in a persistent store (database), so that if the service goes down, once it comes back up, Spring can continue processing

• Provide an API endpoint that shows the size of the queue so that the administrator could take the service down once the queue is empty

  • This would not address the issue if the stock management service crashes