Global rescue triggers after transactional fixture has rolled back (Rspec, ...)

[cmrd-senya]

When rspec's use_transactional_fixtures is true and you run rspec with rescue, RSpec::Expectations::ExpectationNotMetError get caught properly and pry session starts. However at this point ROLLBACK has already been performed, thus making the db state different from the one that was at the expectation verification point, thus making it less usefull to stop at that point.

Is there any simple workaround or a proper fix for that?

[joallard]

This was left in the dark for a few years, but @cmrd-senya, thanks for reporting this bug. It's actually been bothering me for all those years as a heavy user of RSpec.

I'd be eager to find solutions for it, as it must be a case a lot of Rspec+Rails+Rescue users run into.

[joallard]

Writing a mini-test case here.

Scenario: Bug case
  Given I run spec file:
  """rb
    require 'pry-rescue/rspec'

    it do
      User.create!

      Pry.rescue do
        expect(true).to be false
      end
    end
  """
  # And Pry is started

  When I enter 'User.count'
  Then I get '0'  # expecting 1

Scenario: Workaround
  Given I run spec file:
  """rb
    it do
      User.create!

      Pry.rescue do
        expect(true).to be false
      end
    end
  """
  # And Pry is started

  When I enter 'User.count'
  Then I get '1'

[ConradIrwin]

The trick here will be to change where pry-rescue hooks in. Currently it is (I believe) added as a after hook, and so by the time the hook is reached the stack has been unwound, which causes other hooks to fire.

You may be able to re-order the hooks to ensure it always gets to rescue "first", or do some more wizardry to potentially prevent the raise from happening (we already hook into raising to capture the stack correctly, so maybe we could just dump you into pry at that point instead of waiting for the test failure?)