Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Niad 2858: storing negative ack error code in DB #359

Merged
merged 13 commits into from
Nov 6, 2023
Merged

Niad 2858: storing negative ack error code in DB #359

merged 13 commits into from
Nov 6, 2023

Conversation

ole4ryb
Copy link
Contributor

@ole4ryb ole4ryb commented Nov 3, 2023

What

Capturing negative ack error code in DB

Why

PS Adaptor doesn't record/store original error code sent by an incumbent in case of a failure. There is a requirement by NHS England to send failure details hence there should be some mechanism to capture it in PS Adaptor in order to give an access to such information when required.

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Internal change (non-breaking change with no effect on the functionality affecting end users)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • I have performed a self-review of my code
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have updated the Changelog with details of my change in the UNRELEASED section if this change will affect end users
  • A corresponding change has been made to the Mapping Documentation repository

@ole4ryb ole4ryb changed the title Niad 2858 Niad 2858: storing negative ack error code in DB Nov 3, 2023
@ole4ryb ole4ryb marked this pull request as ready for review November 3, 2023 15:50
@@ -94,7 +94,7 @@ public boolean handleMessage(Message message) {
// Current child try catch blocks do not detect this condition so no failed migration log is added...
// We are however unlikely to have a payload at this point so cannot send a NACK
if (conversationId != null && !conversationId.isEmpty()) {
migrationStatusLogService.addMigrationStatusLog(EHR_GENERAL_PROCESSING_ERROR, conversationId, null);
migrationStatusLogService.addMigrationStatusLog(EHR_GENERAL_PROCESSING_ERROR, conversationId, null, "99");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another 99 I'm curious about.

@@ -171,7 +171,7 @@ private void handleMigrationTimeout(PatientMigrationRequest migrationRequest, NA
LOGGER.error("Error retrieving persist duration: [{}]", e.getMessage());
} catch (JsonProcessingException | SAXException | DateTimeParseException | JAXBException e) {
LOGGER.error("Error parsing inbound message from database");
migrationStatusLogService.addMigrationStatusLog(EHR_GENERAL_PROCESSING_ERROR, conversationId, null);
migrationStatusLogService.addMigrationStatusLog(EHR_GENERAL_PROCESSING_ERROR, conversationId, null, "99");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the thinking behind "99" in this case. I'm not sure I have an alternative suggestion as to what we could do here, just curious as to the thinking.

@@ -43,12 +43,12 @@ public boolean prepareAndSendRequest(TransferRequestMessage message) {
LOGGER.debug(response);
} catch (WebClientResponseException wcre) {
LOGGER.error("Received an ERROR response from MHS: [{}]", wcre.getMessage());
migrationStatusLogService.addMigrationStatusLog(MigrationStatus.EHR_EXTRACT_REQUEST_ERROR, conversationId, null);
migrationStatusLogService.addMigrationStatusLog(MigrationStatus.EHR_EXTRACT_REQUEST_ERROR, conversationId, null, "2");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"2" is mysterious. I thought GP2GP errors were all 2 digits.

Also, I wonder if it makes sense to refererence an enum of valid GP2GP error codes. That way this line of code would become more understandable.

Update: Looking at the NACKReason enum, I can't see a 2. 🤔

@@ -41,7 +41,7 @@ public void prepareAndSendRequest(ContinueRequestData data) {
mhsClientService.send(request);
} catch (WebClientResponseException webClientResponseException) {
LOGGER.error("Received an ERROR response from MHS: [{}]", webClientResponseException.getMessage());
migrationStatusLogService.addMigrationStatusLog(MigrationStatus.CONTINUE_REQUEST_ERROR, data.getConversationId(), null);
migrationStatusLogService.addMigrationStatusLog(MigrationStatus.CONTINUE_REQUEST_ERROR, data.getConversationId(), null, "8");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar comment to the "2" comment below.

@@ -1280,7 +1280,7 @@ public void When_HandleMessage_With_AttachmentProcessingErrorNotStorageCause_Exp
assertThat(nackMessageDataCaptor.getValue().getNackCode()).isEqualTo(LARGE_MESSAGE_ATTACHMENTS_NOT_RECEIVED.getCode());

verify(migrationStatusLogService, times(1))
.addMigrationStatusLog(LARGE_MESSAGE_ATTACHMENTS_NOT_RECEIVED.getMigrationStatus(), CONVERSATION_ID, null);
.addMigrationStatusLog(LARGE_MESSAGE_ATTACHMENTS_NOT_RECEIVED.getMigrationStatus(), CONVERSATION_ID, null, "31");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's interesting here is that LARGE_MESSAGE_ATTACHMENTS_NOT_RECEIVED already has the code associated with it.

Perhaps this suggests we should have a new method called .addNackMigrationStatusLog which takes in a NACKReason. Thoughts?


<changeSet id="14" author="ole4ryb">
<addColumn schemaName="public" tableName="migration_status_log">
<column name="error_code" type="varchar(255)">
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we should be clear in the name that this is a GP2GP Error Code.

@@ -150,7 +150,7 @@ public void handleMessage(InboundMessage inboundMessage, String conversationId)
} else {
failMigration(conversationId, LARGE_MESSAGE_ATTACHMENTS_NOT_RECEIVED);
migrationStatusLogService.addMigrationStatusLog(
LARGE_MESSAGE_ATTACHMENTS_NOT_RECEIVED.getMigrationStatus(), conversationId, null);
LARGE_MESSAGE_ATTACHMENTS_NOT_RECEIVED.getMigrationStatus(), conversationId, null, "31");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mysterious 31.

@ole4ryb ole4ryb merged commit a8017d4 into main Nov 6, 2023
@ole4ryb ole4ryb deleted the NIAD-2858 branch November 6, 2023 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants