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

Confusing default behavior, possibly due to default_retry_count #56

Open
crawfoal opened this issue Mar 26, 2016 · 1 comment
Open

Confusing default behavior, possibly due to default_retry_count #56

crawfoal opened this issue Mar 26, 2016 · 1 comment

Comments

@crawfoal
Copy link

I just started using this gem, and I set up the following configuration:

RSpec.configure do |config|
  config.verbose_retry = true # show retry status in spec process
  config.default_retry_count = 4
  config.exceptions_to_retry = [Net::ReadTimeout] # only retry if this exception was thrown
end

I didn't tag any examples with :retry, because I had been looking at this answer on Stackoverflow, and got the impression that if I had this configuration, all examples that failed due to a Net::ReadTimeout error would be retried up to 4 times.

When I ran my test suite, my ouput included this:

Athlete logs a climb
  from the dashboard
[status message] Turning on truncation for the following example.
    for a nearby gym (PENDING: need to work out geolocation stubbing...)
[status message] Turning on truncation for the following example.
    for a recent gym (FAILED - 1)

User edits profile:
[status message] Turning on truncation for the following example.
  name can be changed (FAILED - 2)
[status message] Turning on truncation for the following example.
  user can select roles (FAILED - 3)

User signs out
[status message] Turning on truncation for the following example.
2nd Try error in ./spec/features/users/logout_spec.rb:4:
 Net::ReadTimeout 

RSpec::Retry: 2nd try ./spec/features/users/logout_spec.rb:4
  with valid session

# ... (omitted output) ...

Failures:

  1) Athlete logs a climb from the dashboard for a recent gym
     Got 0 failures and 2 other errors:

     1.1) Failure/Error: visit root_path

          Net::ReadTimeout:
            Net::ReadTimeout
          # ./spec/support/helpers/feature_helper.rb:14:in `capybara_login'
          # ./spec/features/athlete_logs_climb_spec.rb:62:in `block (3 levels) in <top (required)>'
          # ------------------
          # --- Caused by: ---
          # IO::EAGAINWaitReadable:
          #   Resource temporarily unavailable - read would block
          #   ./spec/support/helpers/feature_helper.rb:14:in `capybara_login'

     1.2) Failure/Error: raise Net::ReadTimeout

          Net::ReadTimeout:
            Net::ReadTimeout
          # /home/runner/.rbenv/versions/2.2.2/lib/ruby/2.2.0/net/protocol.rb:158:in `rescue in rbuf_fill'
          # /home/runner/.rbenv/versions/2.2.2/lib/ruby/2.2.0/net/protocol.rb:152:in `rbuf_fill'
          # /home/runner/.rbenv/versions/2.2.2/lib/ruby/2.2.0/net/protocol.rb:134:in `readuntil'

# ... (omitted output) ...

So I'm not sure whether those first examples that failed were retried 3 times, but the verbose message just wasn't printed, or whether they weren't retried at all. Based on how long those examples took to run compared to how long they normally take, I would suspect that they were each retried 3 times, but the message just wasn't output... is this intended behavior?

Also, the readme makes it sound like you have to either add the :retry tag to the example, or do something like this:

  # run retry only on features
  config.around :each, :js do |ex|
    ex.run_with_retry retry: 3
  end

in order for any retrying to occur, but it looks like if you specify a default_retry_count, this applies to all examples, not just the tagged ones.

@michaelglass
Copy link
Contributor

Can you still reproduce this? Do you have suggestions for better copy in the readme? Happy to accept any PRs.

was display_try_failure_messages set to true?

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

No branches or pull requests

2 participants