Fix distribution flaky test

[dorner]

Summary

This fails randomly but fairly often:

  1) Distributions When creating a new distribution manually when the quantity is lower than the on hand recommended quantity should display an alert
     Failure/Error: select item.name, from: "distribution_line_items_attributes_0_item_id"

     Ferrum::JavaScriptError:
       TypeError: Cannot read properties of null (reading 'dispatchEvent')
           at Cuprite.trigger (<anonymous>:412:10)
           at Cuprite.select (<anonymous>:359:12)
           at HTMLOptionElement.<anonymous> (<anonymous>:1:31)

     [Screenshot Image]: /home/runner/work/human-essentials/human-essentials/tmp/capybara/failures_r_spec_example_groups_distributions_when_creating_a_new_distribution_manually_when_the_quantity_is_lower_than_the_on_hand_recommended_quantity_should_display_an_alert_27.png


     # ./spec/system/distribution_system_spec.rb:122:in `block (4 levels) in <top (required)>'

Things to consider

More info for this particular run:

/opt/hostedtoolcache/Ruby/3.2.2/x64/bin/ruby -I/home/runner/work/human-essentials/human-essentials/vendor/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/lib:/home/runner/work/human-essentials/human-essentials/vendor/bundle/ruby/3.2.0/gems/rspec-support-3.13.1/lib /home/runner/work/human-essentials/human-essentials/vendor/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/exe/rspec  --format documentation --format KnapsackPro::Formatters::TimeTracker --default-path spec "spec/requests/admin/barcode_items_requests_spec.rb" "spec/requests/admin/users_requests_spec.rb" "spec/requests/dashboard_requests_spec.rb" "spec/requests/item_categories_requests_spec.rb" "spec/requests/partners/distributions_spec.rb" "spec/requests/partners/requests_spec.rb" "spec/requests/purchases_requests_spec.rb" "spec/requests/transfers_requests_spec.rb" "spec/system/adjustment_system_spec.rb" "spec/system/admin/users_system_spec.rb" "spec/system/distribution_system_spec.rb" "spec/system/layout_system_spec.rb" "spec/system/partner_system_spec.rb" "spec/system/partners/partner_distribution_system_spec.rb" "spec/system/question_system_spec.rb"

Randomized with seed 49610

Criteria for Completion

• [] Test no longer fails randomly

[callmarx]

Hi @dorner, I think that is also related with the failing test that I've been getting on my PR.

Locally, I could't replicate the error that you described even using the same seed and executing with:

bundle exec rspec --format documentation --format KnapsackPro::Formatters::TimeTracker --seed 49610 --default-path spec "spec/requests/admin/barcode_items_requests_spec.rb" "spec/requests/admin/users_requests_spec.rb" "spec/requests/dashboard_requests_spec.rb" "spec/requests/item_categories_requests_spec.rb" "spec/requests/partners/distributions_spec.rb" "spec/requests/partners/requests_spec.rb" "spec/requests/purchases_requests_spec.rb" "spec/requests/transfers_requests_spec.rb" "spec/system/adjustment_system_spec.rb" "spec/system/admin/users_system_spec.rb" "spec/system/distribution_system_spec.rb" "spec/system/layout_system_spec.rb" "spec/system/partner_system_spec.rb" "spec/system/partners/partner_distribution_system_spec.rb" "spec/system/question_system_spec.rb"

However, when running it multiple times with random seeds, I encountered a similar error in another test:

Failures:

  1) Adjustment management With a new adjustment with a storage location that is bare allows you to choose items that do not yet exist
     Failure/Error: select Item.active.last.name, from: "adjustment_line_items_attributes_0_item_id"

     Ferrum::JavaScriptError:
       TypeError: Cannot read properties of null (reading 'dispatchEvent')
           at Cuprite.trigger (<anonymous>:412:10)
           at Cuprite.select (<anonymous>:359:12)
           at HTMLOptionElement.<anonymous> (<anonymous>:1:31)

     [Screenshot Image]: /home/callmarx/OpenSource/human-essentials/tmp/screenshots/failures_r_spec_example_groups_adjustment_management_with_a_new_adjustment_with_a_storage_location_that_is_bare_allows_you_to_choose_items_that_do_not_yet_exist_653.png


     # ./spec/system/adjustment_system_spec.rb:24:in `block (4 levels) in <top (required)>'

Here you can see another flaky failure within the same batch of tests that occurred in the CI environment:

Failures:

  1) Partner management #show when exporting as CSV when filtering preserves the filter constraints in the CSV output
     Failure/Error: expect(downloads.length).to eq(1)

       expected: 1
            got: 2

       (compared using ==)

     [Screenshot Image]: /home/runner/work/human-essentials/human-essentials/tmp/capybara/failures_r_spec_example_groups_partner_management_show_when_exporting_as_csv_when_filtering_preserves_the_filter_constraints_in_the_csv_output_375.png


     # ./spec/system/partner_system_spec.rb:304:in `block (6 levels) in <top (required)>'

Should I focus solely on addressing these selection failures, or should I also investigate the issue with the downloaded CSV?

[dorner]

Maybe make a separate GitHub issue for the CSV problem? Let's not require both to be fixed for this issue to be addressed.

[elasticspoon]

I am not sure about the fix but I am pretty sure the problem is:

select @partner.name, from: "Partner"
select @storage_location.name, from: "From storage location"
select item.name, from: "distribution_line_items_attributes_0_item_id"
select @storage_location.name, from: "distribution_storage_location_id"
fill_in "distribution_line_items_attributes_0_quantity", with: 18

When the page loads the select box distribution_line_items_attributes_0_item_id is not populated. There is some JS on the page that runs when you select a storage location to populate that select with the items from that storage location.

I am guessing in CI the AJAX request is slow from time to time and by the time it tries to do select item.name, from: "distribution_line_items_attributes_0_item_id" the select does not have that item yet.

I think the solution is to somehow wait for that select to get populated, but off the top of my head I don't know the best approach. I am also unsure how to set up Capybara in such a way that is throttled to try and replicate the issue.

But I think what I wrote is the crux of the issue.

[dorner]

You can tell Capybara to wait for a particular CSS or XPath selector to resolve to something. So as long as you can describe what you're actually looking for using one of those two styles, you should be OK.