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

FI-3182 Inferno execute unified short ids option #540

Merged
merged 22 commits into from
Oct 24, 2024

Conversation

Shaumik-Ashraf
Copy link
Contributor

@Shaumik-Ashraf Shaumik-Ashraf commented Oct 4, 2024

Summary

Create command line option that allows for unified short ids --short-ids (alias: -r)

Testing Guidance See Below

  1. checkout this branch
  2. bundle exec inferno services start
  3. verify old behavior
bundle exec inferno execute --suite infra_test --groups 1 --tests 4.01 --inputs suite_input:a outer_group_input:b inner_group_input:c test_input:d external_test1_input:asdf external_inner_group_input:asdf external_outer_group_input:asdf
  1. verify new behavior
bundle exec inferno execute --suite infra_test --short-ids 1 4.01 --inputs suite_input:a outer_group_input:b inner_group_input:c test_input:d external_test1_input:asdf external_inner_group_input:asdf external_outer_group_input:asdf
  1. this should raise an exception to prevent running 1.01 twice
bundle exec inferno execute --suite dev_validator -r 1 1.01 -i "url:https://hapi.fhir.org/baseR4" patient_id:1234321

@Shaumik-Ashraf Shaumik-Ashraf self-assigned this Oct 4, 2024
Copy link

codecov bot commented Oct 4, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.08%. Comparing base (5b83481) to head (805f4a9).
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #540   +/-   ##
=======================================
  Coverage   84.08%   84.08%           
=======================================
  Files         261      261           
  Lines       11392    11392           
  Branches     1252     1252           
=======================================
  Hits         9579     9579           
  Misses       1803     1803           
  Partials       10       10           
Flag Coverage Δ
backend 92.18% <ø> (ø)
frontend 79.35% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

end
end

def shorts
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a reason this isn't called short_ids?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Its returning the actual test entities instead of ids.

Copy link
Collaborator

Choose a reason for hiding this comment

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

In that case, this method name makes no sense.

@@ -201,11 +266,11 @@ def print_error_and_exit(err, code)
end

def runnable_type(runnable)
if Inferno::TestSuite.subclasses.include? runnable
if Inferno::TestSuite.subclasses.include?(runnable) || runnable.ancestors.include?(Inferno::TestSuite)
Copy link
Collaborator

Choose a reason for hiding this comment

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

if runnable < Inferno::TestSuite

# Since Inferno can only have one test_run executing at a time per test_session,
# and each call to `inferno execute` represents one test_session, we block until
# each runnable until result is achieved
block_until_result_for(runnable)
Copy link
Collaborator

Choose a reason for hiding this comment

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

How are tests running asynchronously? Why does the short id require this change, wasn't this exact behavior already available just using test ids and group ids rather short ids?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My bad I mixed up executing test_run with instantiating test run. Yes jobs are already running synchronously and this is now removed.

# sort so if a user specifies `inferno execute --tests 1.01 --short-ids 1.02` it will run in order 1.01, 1.02
# although this will disallow if a user wanted to intentionally run `inferno execute --tests 1.02 1.01` in
# that order
@selected_runnables ||= validate_unique_runnables(shorts + groups + tests).sort do |a, b|
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we should sort, I think we should execute things in the order specified by the user.

@@ -165,6 +191,41 @@ def dispatch_job(test_run)
end
end

def validate_unique_runnables(runnables)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why do we care to validate this? Why should this prevent someone from running tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There was glitchy behavior observed when a user tried to run the same test entity multiple times in one execute call. It may relate to the fact that Inferno core will create a result once all the children of a test entity have a result, but I haven't exactly proved it's due to that. It's easier to prevent this behavior than fix it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I get that the Inferno REST API allows re-running the same entity over one session, and one execute call is reflecting one session, but the client also blocks spamming requests and possibly filters the results returned. When we tackle the other bug or give inferno execute more control over sessions we can re-enable this behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or I could undo it and leave the sharp tools with the user?

Copy link
Collaborator

Choose a reason for hiding this comment

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

There was glitchy behavior observed when a user tried to run the same test entity multiple times in one execute call. It may relate to the fact that Inferno core will create a result once all the children of a test entity have a result, but I haven't exactly proved it's due to that. It's easier to prevent this behavior than fix it.

This change is similar to the async test execution change where it doesn't seem related to the purpose of the ticket. We should connect and discuss problem this is intended to prevent, because I'm willing to bet that the fix is simpler than this code.


@shorts ||= options[:short_ids]&.map do |short_id|
find_by_short_id(test_groups_repo, short_id)
rescue StandardError => maybe_not_found_error # rubocop:disable Naming/RescuedExceptionsVariableName
Copy link
Collaborator

Choose a reason for hiding this comment

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

find_by_short_id should do what it says without requiring rescuing errors.

@Shaumik-Ashraf
Copy link
Contributor Author

Shaumik-Ashraf commented Oct 18, 2024

Updated testing guidance

  1. Checkout this branch
  2. bundle exec inferno services start
  3. verify old behavior
bundle exec inferno execute --suite infra_test --groups 1 --tests 4.01 --inputs suite_input:a outer_group_input:b inner_group_input:c test_input:d
  1. verify new behavior
bundle exec inferno execute --suite infra_test --short-ids 1 4.01 --inputs suite_input:a outer_group_input:b inner_group_input:c test_input:d
  1. this should raise an exception to prevent running 1.01 twice now work, and show two results from 1.01 (one from group 1, and one from the test)
bundle exec inferno execute --suite dev_validator -r 1 1.01 -i "url:https://hapi.fhir.org/baseR4" patient_id:1234321

@@ -165,23 +172,54 @@ def dispatch_job(test_run)
end
end

def runnable_is_included_in?(runnable, maybe_parent)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is dead code now, right?

run_one(suite, test_run)

# TODO: make results more intuitively ordered than just reversing
results = test_runs_repo.results_for_test_run(test_run.id).reverse
Copy link
Collaborator

Choose a reason for hiding this comment

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

Here and in line 55, replace reverse with:

.sort { |result, other| result.runnable.short_id <=> other.runnable.short_id }

Copy link
Collaborator

Choose a reason for hiding this comment

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

I asked for this change here and in lines 49 and 55 (now 48 and 54). Making the change in line 62 is not the same behavior and is not correct.

Copy link
Contributor Author

@Shaumik-Ashraf Shaumik-Ashraf Oct 24, 2024

Choose a reason for hiding this comment

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

It's because rubocop says that this hits the cyclomatic complexity limit

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also suites don't have short ids so I had to make those if statements. Suites appear last my implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would actually argue to raise or disable the cyclomatic complexity limit in rubocop, but decided I'll ask that in a future PR

Copy link
Collaborator

Choose a reason for hiding this comment

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

But the behavior is wrong.

loop do
  results += results.sort
end
results

is not the same as

loop do
  results += results
end
results.sort

Suites should also definitely come first.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

results += results.sort is the desired behavior right?

@Shaumik-Ashraf
Copy link
Contributor Author

Okay behavior should be correct now

@Shaumik-Ashraf Shaumik-Ashraf merged commit 1b13c9b into main Oct 24, 2024
10 checks passed
@Shaumik-Ashraf Shaumik-Ashraf deleted the fi-3182-clean-diff branch October 24, 2024 17:57
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