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

Fix submission history bugs and add integration test cases #15893

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

thetaurean
Copy link
Collaborator

This PR fixes two bugs related to submission history and adds relevant tests to prevent reoccurrence.

Test Steps:

  1. Run test suites

Changes

  • Submission history checks nextAction on latest report in lineage for reports without destinations
  • Submission history checks latest action instead of earliest

Checklist

Testing

  • Tested locally?
  • Added tests?

Linked Issues

@thetaurean thetaurean added the platform Platform Team label Sep 16, 2024
@thetaurean thetaurean requested a review from a team as a code owner September 16, 2024 15:05
Copy link

github-actions bot commented Sep 16, 2024

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

PackageVersionScoreDetails

Scanned Manifest Files

Copy link

github-actions bot commented Sep 16, 2024

Test Results

1 230 tests  +1   1 225 ✅ ±0   7m 13s ⏱️ +4s
  162 suites +1       4 💤 ±0 
  162 files   +1       1 ❌ +1 

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.

Copy link

github-actions bot commented Sep 16, 2024

Integration Test Results

0 files   -  53  0 suites   - 53   0s ⏱️ - 27m 49s
0 tests  - 410  0 ✅  - 401  0 💤  - 9  0 ❌ ±0 
0 runs   - 413  0 ✅  - 404  0 💤  - 9  0 ❌ ±0 

Results for commit f39a91f. ± Comparison against base commit fe3d9d7.

♻️ This comment has been updated with latest results.

Copy link
Collaborator

@brick-green brick-green left a 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
Copy link
Collaborator

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.

Copy link
Collaborator Author

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 }
Copy link
Collaborator

Choose a reason for hiding this comment

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

Delete this comment

Copy link
Collaborator

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
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

@mkalish mkalish left a 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
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

@thetaurean thetaurean Sep 17, 2024

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 {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this used?

Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform Platform Team
Projects
None yet
3 participants