Error on running bundle exec rake

[Anuj Dutta]

Hello all,

Has anyone had any issues running the tests in vcr source from github master? I get this error message:

process still alive after 30 seconds (ChildProcess::TimeoutError) 

I looked up aruba's docs and 30 seconds seems like a generous timeout. I also checked vcr's travis builds and there seems to a recent build failure due to the exact same reason. 

Any ideas or pointers?

Thanks.

Kind regards,

Anuj

[Myron Marston]

So you've hit upon the main thing that needs work right now -- getting the travis builds to pass consistently.  Locally, I can't reproduce the timeouts (which means it's very hard for me to troubleshoot and solve the issue!) but they seem to happen consistently on Travis (at least for ruby 2.0 and 2.1 -- for 1.9.2 and 1.9.3 the build seems to pass consistently).  I've tried locally on multiple ruby versions (in fact I did just now) and they are all green for me.

I'd say it's actually lucky that you're getting those failures; that gives you a chance to troubleshoot the travis failures locally and hopefully solve one of the biggest issues VCR has right now!  It's hard to move VCR forward with confidence w/o having passing builds and so it's important to VCR's future to get to the bottom of this.

Anyhow, as to why these failures are happening -- I believe that it is environmental.  There's something in the travis build environment and in your environment that causes this to happen, but not in my environment.

Looking at the travis build logs, this is the last passing build:

https://travis-ci.org/vcr/vcr/builds/34680755

It's from two months ago.  No build has passed since then.  FWIW, here's the code diff from that passing build until now:

https://github.com/vcr/vcr/compare/a2185623132b27a809b41789b6bcaf9596da827f...master

There are some gem upgrades in there, which could be at fault (although again, locally I can't reproduce even with those newer versions).

--
You received this message because you are subscribed to the Google Groups "vcr-maintainers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vcr-maintaine...@googlegroups.com.
To post to this group, send email to vcr-mai...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vcr-maintainers/d3781acc-286b-45f5-ae84-9e1ed8459ae0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Myron Marston]

BTW, Anuj, which cucumber scenarios do you get that error for?  Or is it for all of them (hopefully not...)?

On Monday, December 1, 2014 12:49:39 PM UTC-8, Myron Marston wrote:

So you've hit upon the main thing that needs work right now -- getting the travis builds to pass consistently.  Locally, I can't reproduce the timeouts (which means it's very hard for me to troubleshoot and solve the issue!) but they seem to happen consistently on Travis (at least for ruby 2.0 and 2.1 -- for 1.9.2 and 1.9.3 the build seems to pass consistently).  I've tried locally on multiple ruby versions (in fact I did just now) and they are all green for me.

I'd say it's actually lucky that you're getting those failures; that gives you a chance to troubleshoot the travis failures locally and hopefully solve one of the biggest issues VCR has right now!  It's hard to move VCR forward with confidence w/o having passing builds and so it's important to VCR's future to get to the bottom of this.

Anyhow, as to why these failures are happening -- I believe that it is environmental.  There's something in the travis build environment and in your environment that causes this to happen, but not in my environment.

Looking at the travis build logs, this is the last passing build:

https://travis-ci.org/vcr/vcr/builds/34680755

It's from two months ago.  No build has passed since then.  FWIW, here's the code diff from that passing build until now:

https://github.com/vcr/vcr/compare/a2185623132b27a809b41789b6bcaf9596da827f...master

There are some gem upgrades in there, which could be at fault (although again, locally I can't reproduce even with those newer versions).

On Mon, Dec 1, 2014 at 11:59 AM, Anuj Dutta <> wrote:

Hello all,

Has anyone had any issues running the tests in vcr source from github master? I get this error message:

process still alive after 30 seconds (ChildProcess::TimeoutError) 

I looked up aruba's docs and 30 seconds seems like a generous timeout. I also checked vcr's travis builds and there seems to a recent build failure due to the exact same reason. 

Any ideas or pointers?

Thanks.

Kind regards,

Anuj

--
You received this message because you are subscribed to the Google Groups "vcr-maintainers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vcr-maintainers+unsubscribe@googlegroups.com.
To post to this group, send email to vcr-maintainers@googlegroups.com.

[Anuj Dutta]

Hello all,

I have figured out the issue with my local set-up, and, believe it or not, it was Redis. Let's give you guys a detailed analysis of steps I took:

1. Checked out previous passing commits on Travis and ran that locally, but they failed as well.

2.  I ran the failing features individually and they all passed.

3. I spotted that one of the failures complained by the unavailability of Redis. I ran my local redis server and it turned green.

So, the first thing I'd like to change is the 'Contributing' doc to update the significance of redis in running specs.

Myron,

Could you explain us in a bit more detail the role of redis in the test suite? I've not had a change to look closely at the codebase. I am just too chuffed to see green again.

Thanks.

Regards,

Anuj

On Tuesday, 2 December 2014 00:04:45 UTC, Myron Marston wrote:

BTW, Anuj, which cucumber scenarios do you get that error for?  Or is it for all of them (hopefully not...)?

On Monday, December 1, 2014 12:49:39 PM UTC-8, Myron Marston wrote:

So you've hit upon the main thing that needs work right now -- getting the travis builds to pass consistently.  Locally, I can't reproduce the timeouts (which means it's very hard for me to troubleshoot and solve the issue!) but they seem to happen consistently on Travis (at least for ruby 2.0 and 2.1 -- for 1.9.2 and 1.9.3 the build seems to pass consistently).  I've tried locally on multiple ruby versions (in fact I did just now) and they are all green for me.

I'd say it's actually lucky that you're getting those failures; that gives you a chance to troubleshoot the travis failures locally and hopefully solve one of the biggest issues VCR has right now!  It's hard to move VCR forward with confidence w/o having passing builds and so it's important to VCR's future to get to the bottom of this.

Anyhow, as to why these failures are happening -- I believe that it is environmental.  There's something in the travis build environment and in your environment that causes this to happen, but not in my environment.

Looking at the travis build logs, this is the last passing build:

https://travis-ci.org/vcr/vcr/builds/34680755

It's from two months ago.  No build has passed since then.  FWIW, here's the code diff from that passing build until now:

https://github.com/vcr/vcr/compare/a2185623132b27a809b41789b6bcaf9596da827f...master

There are some gem upgrades in there, which could be at fault (although again, locally I can't reproduce even with those newer versions).

On Mon, Dec 1, 2014 at 11:59 AM, Anuj Dutta <> wrote:

Hello all,

Has anyone had any issues running the tests in vcr source from github master? I get this error message:

process still alive after 30 seconds (ChildProcess::TimeoutError) 

I looked up aruba's docs and 30 seconds seems like a generous timeout. I also checked vcr's travis builds and there seems to a recent build failure due to the exact same reason. 

Any ideas or pointers?

Thanks.

Kind regards,

Anuj

--
You received this message because you are subscribed to the Google Groups "vcr-maintainers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vcr-maintaine...@googlegroups.com.
To post to this group, send email to vcr-mai...@googlegroups.com.

[Myron Marston]

Redis is only used by one cucumber scenario:

https://relishapp.com/vcr/vcr/v/2-9-3/docs/cassettes/cassette-persistence

There it's just being used as a demonstration of a custom persister (as an alternative to storing cassettes on the file system).  If you have an idea for how to demonstrate that feature without using a datastore like redis we can consider changing it so that it no longer uses redis.

I don't think redis is causing the failures on travis, though; travis is configured to run redis and the failures don't seem to be connected.

Are you seeing any other failures?

Myron

To view this discussion on the web visit https://groups.google.com/d/msgid/vcr-maintainers/1b68e2b0-46ca-461b-a47d-48f3cb967b7c%40googlegroups.com.

[Anuj Dutta]

Hello,

So, I tried running the test suite on a  Ubuntu vm since my Mac has some issues. On Ubuntu vm,  it worked just fine with one test failure (to do with redis not running, which is what Myron said in an earlier email).

I will have to investigate further to see the reason for failures on my mac book pro.

Will keep you guys posted.

Thanks.

Anuj

[Myron Marston]

Thanks Anuj.  I'm glad to see someone digging into this :).

[Anuj Dutta]

Hello,

I've got some update. I've been digging into it a bit more and found that increasing the @aruba_timeout_seconds, to 50 seconds makes the errors go away. As per Aruba readme,

A process sometimes takes longer than expected to terminate, and Aruba will kill them off (and fail your scenario) 

This is exactly what happens on my local machine. The child process takes longer than the @aruba_timeout_seconds time (30 seconds in master) to terminate on my machine and a ChildProcess::TimeoutError is thrown.

I am not sure why the process termination time is higher on my local. Do you know a way to investigate it? Also, can we try changing the timeout and see if it passes on Travis just for argument sake. It doesn't feel like the right solution to the problem and I'd appreciate some suggestions and pointers in the right direction.

Thanks.

Kind regards,

Anuj

--

Anuj DUTTA

Suggestion.io

Product suggestion wizards for e-commerce!

NewsTrapper

Track news and never miss an update!

Andhapp

Humble abode

AndhappLimited

Consultancy

[Myron Marston]

Can you open a PR increasing the build timeouts?

[Anuj Dutta]

I opened the PR and it's ran on Travis (still running for jruby) and it seems the 60 seconds timeout is fine for most of the features. I will let you have a look at it yourself and let me know your thoughts.

Cheers.

Anuj