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

update submission received event and delete v1 azure events #15990

Merged

Conversation

brick-green
Copy link
Collaborator

@brick-green brick-green commented Sep 24, 2024

This PR deletes the v1 azure event data classes and improves the event emitted from the submission controller. It now includes queryParamters, httpMethod, and full request url.

Test Steps:

  1. ./gradlew bootRun to make sure it compiles
  2. run submissionController tests
  3. run submissionControllerIntegration tests

Changes

  • update SubmissionReceivedEvent
  • add retrieval and filtering for query parameters
  • retrieve url and http method
  • delete unused azure event data classes

Checklist

Testing

  • Tested locally?
  • Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?

Linked Issues

@brick-green brick-green added the platform Platform Team label Sep 24, 2024
Copy link

github-actions bot commented Sep 24, 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 24, 2024

Test Results

1 232 tests  ±0   1 228 ✅ ±0   7m 21s ⏱️ -18s
  162 suites ±0       4 💤 ±0 
  162 files   ±0       0 ❌ ±0 

Results for commit 14f52b8. ± Comparison against base commit 2294f83.

♻️ This comment has been updated with latest results.

Copy link

github-actions bot commented Sep 24, 2024

Integration Test Results

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

Results for commit 14f52b8. ± Comparison against base commit 2294f83.

♻️ This comment has been updated with latest results.

@brick-green brick-green marked this pull request as ready for review September 24, 2024 19:47
@brick-green brick-green requested a review from a team as a code owner September 24, 2024 19:47
@jalbinson jalbinson self-assigned this Sep 25, 2024
| mv-expand conditions
| extend conditionDisplay = tostring(conditions.display)
| where name == "ITEM_ACCEPTED"
| extend conditionDisplay = tostring(parse_json(tostring(parse_json(tostring(parse_json(tostring(parse_json(tostring(parse_json(tostring(customDimensions.params)).bundleDigest)).observationSummaries))[0].testSummary))[0].conditions))[0].display)
Copy link
Collaborator

Choose a reason for hiding this comment

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

there has to be a better way 😆

If it works, it works though.

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 just used the UI in azure to extend on that field and that's what it gave me. I agree it looks kinda messy though

blobUrl = blobClient.blobUrl
requestParameters = SubmissionDetails(
filterHeaders(headers),
filterQueryParameters(request.parameterMap.mapValues { it.value.joinToString(",") })
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would we break these headers back apart in the KQL query?

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 don't understand. Those two filter functions return maps of the headers and parameters so that they are separated for querying

Copy link
Collaborator

Choose a reason for hiding this comment

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

if we have the query string ?param=a&param=b&param=c then your code will serialize it to:

mapOf(
  "param" to "a,b,c"
)

So then say we want to look for all events where param contains b we would have to break out "a,b,c" in KQL.

My suggestion is make the fields in SubmissionDetails to Map<String, List<String>> and let jackson do the serialization work so its easier to parse it back to json in KQL.

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 set it up to account for a single query parameter to have multiple values. I did not set it up for headers though as I don't see a use case for that yet. I also think it's a little out of scope for this ticket as I would need to update the queue message then also update the FHIRReceiver to account for the new type. If we ever actually need to accept query parameters we'd also need to do the same.

Copy link
Collaborator

Choose a reason for hiding this comment

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

works for me.

@@ -237,6 +247,11 @@ class SubmissionController(
return headers.filter { it.key.lowercase() in headersToInclude }
}

private fun filterQueryParameters(queryParameters: Map<String, String>): Map<String, String> {
val headersToInclude = emptyList<String>() // update this list as new QueryParameters are needed
Copy link
Collaborator

Choose a reason for hiding this comment

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

This should be moved to configuration.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Same with headers as well.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

moved both to configuration based filtering. Really good call here!

Copy link

sonarcloud bot commented Sep 25, 2024


# Allowed headers
allowed.headers.client_id=client_id
Copy link
Collaborator

@jalbinson jalbinson Sep 25, 2024

Choose a reason for hiding this comment

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

Few things:

This being a map doesn't seem to serve a purpose since both key/value are the same(ish) and you ignore the key in code anyway. In code the type should just be List<String>.

I think adding an additional prefix would help clarify the configuration as well. Something like event.allowed.headers?

Last bit is I think yml really simplifies this file over a properties file. Here's what the result would look like:

event.allowed:
  headers:
    - client_id
    - content-type
    - payloadname
    - x-azure-clientip
    - content-length
  queryParameters:
    - ???

With a properties file there is much more duplication and you need to add indices.

event.allowed.headers[0]=client_id
event.allowed.headers[1]=content-type
...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

got it fixed like this. I did leave it as just allowed since this list is also used to filter out parameters for the queue message

Copy link
Collaborator

@jalbinson jalbinson left a comment

Choose a reason for hiding this comment

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

Looks good! Thanks for bearing with me over the config stuff. Sets us up nicely for down the road.

* A list of allowed HTTP headers that can be accepted by the API.
* Each entry in the list represents a header name expected in the incoming request.
*/
var headers: List<String> = emptyList()
Copy link
Collaborator

Choose a reason for hiding this comment

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

This shouldn't be empty, right? Only queryParams for now? Off the top of my head, payloadName should be supported, along with a few others?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is the field that holds the injected list of allowable header. It's defaulted to an empty list so that if someone in the future wants to allow all headers then they can. The list of allowable headers, including payloadName, is in the application.yml file.

@brick-green brick-green merged commit 1bf38e8 into master Sep 26, 2024
20 of 21 checks passed
@brick-green brick-green deleted the platform/brick/13161-update-submission-received-event branch September 26, 2024 21:07
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
Development

Successfully merging this pull request may close these issues.

3 participants