FI-3263: Huge Bundle Fix #39
Conversation
…dd input to limit entries that are validated
…_valid_bundle_entries, and add filter to limit the number of warning/error messages that appear from the validator
… is a necessary field needed for validation missing
|
@emichaud998 please remove the .gem file, that shouldn't get committed. |
|
|
||
| add_message('error', %( | ||
| Organization with id: #{organization.id} references an Endpoint that is not contained in this | ||
| bundle." |
There was a problem hiding this comment.
| bundle." | |
| bundle. |
Don't need trailing quote.
|
|
||
| @messages = [] | ||
| @messages += error_messages.first(20) unless error_messages.empty? | ||
| @messages += non_error_messages.first(50) unless non_error_messages.empty? |
There was a problem hiding this comment.
@Jammjammjamm -- is this an acceptable method to manually prune error messages coming from the validator so it doesn't crash the interface? I seem to recall the validator currently automatically adds messages to the built-in-message system. This seems risky but i'm not sure we have any other better approach, unless you know of one?
There was a problem hiding this comment.
The validator adds the messages by sticking them in @messages. Those messages are then persisted by the test runner after the test finishes executing, so that part seems fine.
I don't know why we'd want to allow more info/warning messages than error messages, though, as error messages are more important. It's probably also a good idea to put the message saying that only the first xyz messages are being shown first rather than last.
I also think a better solution would be to check if the limit has been reached after each iteration, and then breaking once the limit has been reached. That would prevent performing useless validations and also ensure that all of the messages for each resource validated are kept.
There was a problem hiding this comment.
I was also thinking that would be a better solution, but the issue with that approach is if there are a ton of info/warning messages. The problem I realized with that approach is that if there are a ton of info/warning messages then you might hit the limit of messages and break before you validate a resource that would have had an error and you wouldn't see it, whereas with this approach if there is an error, it will be caught.
Summary
This PR updates the way Service Base URL Bundles are validated so that the Bundle validation test will not fail if the Bundle is extremely large. Rather that sending the full bundle to the validator, the Bundle validation test will test for each of the Bundle constraints and required fields manually. The validator has also been updated to limit the number of validation messages/errors to 50 so that the UI does not get bogged down with validation messages. The
Limit Validation to a Maximum Resource Countinput has been added to give the user the ability to choose how many Bundle resources they want validated. If the user submits that they want X resources validated, Inferno will limit the number of Bundle entries down to around X resources by looping through each Organization resource and adding any referenced endpoints, or parent Organization and it's referenced endpoints. This substantially cuts down the time it takes these tests to run for large Bundles. However, large Bundles can now be ran without Inferno crashing, though it may slow the system down and take a while to complete, around 20-30 minutes depending on the size of the Bundle.Testing Guidance
Ensure running our tests against
https://brand-browser.argo.run/bundle.jsonno longer results in a validator 400 error. Then test out running the tests againsthttps://brand-browser.argo.run/bundle.jsonwith theLimit Validation to a Maximum Resource Countinput populated to view how it cuts down the run time of the tests.