-
Notifications
You must be signed in to change notification settings - Fork 39
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
Fix submission history bugs and add integration test cases #15893
base: master
Are you sure you want to change the base?
Fix submission history bugs and add integration test cases #15893
Conversation
…n receiver filter; add details to filter result message
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Manifest Files |
Test Results1 230 tests +1 1 225 ✅ ±0 7m 13s ⏱️ +4s For more details on these failures, see this check. Results for commit f39a91f. ± Comparison against base commit fe3d9d7. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a couple questions
@@ -165,7 +165,7 @@ class FHIRConverter( | |||
), | |||
metadata = this.metadata, | |||
topic = queueMessage.topic, | |||
nextAction = TaskAction.none | |||
nextAction = TaskAction.destination_filter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain this change? It looks like this Report is created for a message that is not parseable and isn't going to be added to the destination filter queue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch this was left in by mistake; removing.
destination.organizationId == it.receivingOrg && destination.service == it.receivingOrgSvc | ||
}.sortedBy { it.createdAt } | ||
val latestAction = reportsForDestination.first().nextAction | ||
} // .sortedBy { it.createdAt } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete this comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've got a happy path test. Should there be an unhappy test?
@@ -384,7 +398,7 @@ class DetailedSubmissionHistory( | |||
* the receivers. | |||
*/ | |||
return if ( | |||
reports.size > 1 | |||
reports.size > 1 && !hasNextAction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know why this is checking if reports.size is > 1
instead of reports.size is > 0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the assumption is that if we only have one report we must have only received it so far.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Main thought is if we can add more tests to the existing tests file rather than introducing a new pattern.
* Flag to check if there's a next action for a report related to this submission | ||
*/ | ||
@JsonIgnore | ||
var hasNextAction = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally forget how the nextActionScheduled
is used, but maybe they can get collapsed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially I did just modify the related check that sets this flag. But it is used differently in relation to Batch/Send steps so it seemed better to track both states separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if there is a way we can avoid this test since its pretty heavy. Is there a reason we can't do this by just seeding the db directly like the other tests do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent was to create tests that couple the SubmissionHistory to the pipeline steps.
Thinking it over I could have added simpler tests to ensure the pipeline steps output the expected state (with respect to ActionHistory, etc.), then add corresponding tests to the Submission side with that expected state.
Working on this now, though I will leave this new pattern in a branch somewhere in case it becomes useful later on. Arnej has some vision for testing various SubmissionHistory
scenarios that might require it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only problem I see with this approach is that if someone changes the pipeline such that the outputs (ActionLogs, etc.) change, the SubmissionHistory tests won't break because their input is agnostic to any changes in the pipeline. The associated pipeline tests will break (and get fixed) but the SubmissionHistory tests stay happy.
Maybe that's okay though, thoughts? We could always add a comment to the relevant pipeline tests to be wary of the loose coupling to history tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think thats ok? My two cents is that we're just testing that we can correctly read and parse what's been inserted into the DB and that a broader smoketest is what verifies that the whole thing working together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The broader smoketest suite does not catch these bugs. So maybe enhancement is needed there?
Thought for one of these bugs I'm not sure current smoketest design pattern can catch the issue since it only presents at a specific point in the pipeline (after receiver step, before destination filter completion) and smoke tests can't reliably time such a history API call.
@@ -237,6 +240,9 @@ class SubmissionFunctionIntegrationTests { | |||
log(ActionLog(InvalidParamMessage("log"), type = ActionLogLevel.warning)) | |||
reportGraphNode { | |||
action(TaskAction.route) | |||
reportGraphNode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be another assertion change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a look and did not think of any in the context of status/history.
I was thinking maybe an assertion to ensure the lineage is "terminated" so to to speak, but that would just assert against data we inserted.
@@ -115,7 +116,8 @@ open class Receiver( | |||
timeZone = timeZone, | |||
dateTimeFormat = dateTimeFormat, | |||
reverseTheQualityFilter = reverseTheQualityFilter, | |||
enrichmentSchemaNames = enrichmentSchemaNames | |||
enrichmentSchemaNames = enrichmentSchemaNames, | |||
transport = transport |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes used for setting the transport on a receiver to NullTransport
so I can run the send step.
If I change the tests to not run the whole pipeline it will no longer be needed.
This PR fixes two bugs related to submission history and adds relevant tests to prevent reoccurrence.
Test Steps:
Changes
nextAction
on latest report in lineage for reports without destinationsChecklist
Testing
Linked Issues