Date |
|
Authors | |
Status | Done. |
Summary | Some exported placements show an unknown ESR status ( |
Impact | Inaccurate information regarding some placement’s ESR status |
...
: 15:33 BST - Slack notification regarding a high volume of messages in the Dead Letter Queue
: 15:58 BST - Poor interaction between the
InboundDataWriterServiceandTCSidentified as the culprit for messages being discarded when info hadn’t successfully been recorded into TIS: Fix put in place to increase resilience of the
InboundDataWriterServicewhen interacting withTCS: Affected data amended in order to display accurate ESR export status
Root Cause(s)
TCS didn’t have the data to show the tick to say the placement was updated.
The Inbound Data Writer service updates to TCS failed, which is responsible for updating the PlacementEsrEvent table where this data’s stored.
The message was not requeued (therefore re-processing was not attempted), and the updates where not applied.
TCS was momentarily unavailable* right when the Inbound Data Writer service sent the REST call and didn’t accommodate that call. It didn’t update anything.
The Inbound Data Writer service, treated TCS’s unavailability like a problem with the message which aren’t requeued.
*why was TCS unavaliable?
Action Items
Action Items | Owner | Status |
|---|---|---|
Fix current Placements whose status is currently inaccurate | Edward Barclay ongoing | |
Make the Inbound Data Writer service more resilient so it requeues the messages when TCS doesn’t respond | ||
Check elsewhere in the ESR interface for places where requeuing would be appropriate |
...
Lessons Learned
Consider more carefully when it’s appropriate to requeue a message (re-attempt processing it) and when it’s ok not to requeue a message.