Issue #6407 has been updated by James Turnbull. Category set to testing Status changed from Available In Testing Branch to Closed Target version changed from 2.6.x to 2.6.7
---------------------------------------- Bug #6407: Specs hang on zlib test when mocha 0.9.11 is installed https://projects.puppetlabs.com/issues/6407 Author: Matt Robinson Status: Closed Priority: Normal Assignee: Category: testing Target version: 2.6.7 Affected Puppet version: Keywords: Branch: This is annoying to debug what's happening, so should be fixed to prevent others from encountering this when they upgrade their mocha gem. I'll paste in the email from puppet-dev about what's been discovered so far: ---------- Forwarded message ---------- From: Nick Lewis <[email protected]> Date: Wed, Feb 16, 2011 at 1:07 AM Subject: Re: [Puppet-dev] Specs hanging on zlib test To: [email protected] On Wed, Feb 16, 2011 at 12:24 AM, Nick Lewis <[email protected]> wrote: > > On Wed, Feb 16, 2011 at 12:01 AM, Matt Robinson <[email protected]> wrote: >> >> I don't know why, but suddenly spec runs started hanging on my Mac at >> the following test in spec/unit/network/http/compression_spec.rb >> >> it "should raise the error the second time" do >> @inflater.expects(:inflate).raises(Zlib::DataError.new("not a >> zlib stream")) >> Zlib::Inflate.expects(:new).with.returns(@inflater) >> @adapter.uncompress("chunk") >> end >> >> I know Jacob was seeing this issue too a few days ago, so I thought >> I'd ask before I spent too much time banging my head against figuring >> this one out. Any ideas what's causing this? I don't see this >> happening on my VM's, and it's happening in every major branch. >> Matt >> > > The code for this appears bogus. We rescue an exception, and based on a flag > decide to retry with a new instance. But the thing we retry raises its > exception BEFORE it ever has a chance to turn off the flag to retry. And > since we have stubbed it to always return the same instance which raises, it > never gets out. > That said, I can't answer as to why this occasionally doesn't fail. Except > that I seem to recall it being related to Mocha 0.9.10. Is that the version > you're using? The only change in that version was that > Mocha::ExpectationError is no longer caught by broad exception handlers. So > it could be possible that the test had been passing before because an > expectation error was being raised, ignored by the specific handler causing > the retry loop, and causing the test to pass from the raise_error matcher. > And now raise_error isn't matching the expectation error. But I don't know, > in that case, a) where the expectation error would have been coming from > before, b) why it's not showing up somewhere in here (as an uncaught > exception?), c) why it's apparently sporadic. Of course, this is all reasoned > by looking at the code, not from testing anything, so I could be way off. This appears to be due to a change in Mocha 0.9.11 for unexpected invocations. They now include the unexpected invocation itself before failing, whereas previously they would preemptively fail without performing the disallowed invocation. This seems to be so that Mocha's errors will properly say a method expected only once was invoked twice, rather than once. I believe we, at one point, tested an ad-hoc fix for that same misbehavior, which may have been what is triggering my memory of having previously encountered this test failure. In our case, the second invocation that is now happening is, like the first, raising a Zlib::DataError, and getting itself into the retry loop, all while Mocha is waiting for it to return so it can merrily raise its ExpectationError. It seems to me that the retry loop in the code is the genuine bug here, not our test or Mocha (except maybe Mocha a little bit). I am skeptical about the implication that the bug hasn't been encountered in the wild, though. For now, I guess an easy work-around for running the tests is to use an older version of Mocha. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
