Best way to track coverage in a persistent process?

[jjb]

In ruby-clock, I use rails runner to start the persistent process. I think this works well with coverband, but have possibly seen it not work, sometimes (sorry for vagueness, I'm still investigating).

While investigating, I noticed that rails runner and rails console will start Coverband::Background, but rails server does not, because RackServerCheck.running? is true.

So, in a web context, a middleware handles things, but in other contexts, there's a background process. That makes sense.

I also noticed that there is some Rescue-specific code. But there doesn't seem to be specific code for other persistent servers like sidekiq and other job processors.

1. why does rescue get its own code?
2. should we generally expect coverband to track coverage for code run by rails runner?

Thanks!

[danmayer]

Sorry for the delay...

1. resque has some special code to improve how we would handle the out of the box forking nature of resque. The forking model is honestly pretty terrible for things like coverband... I would mostly say avoid forking per unit of work.
2. The threaded model should work fine out of the box just fine...

So the RackRunner is to deal with forking web servers, this is still different than Resque the forks per job, but I needed some way to detect after forks and came up with the middleware Rack model to do that so we could ensure each process had a coordination point for it's threads and such.

If you use rails runner and aren't forking you should be good to go... if you fork in ruby-clock it would be best to think through how to tie in coverband prefork but not start it until after fork... that might mean something like the rack check, resque code, or possibly I could figure out a more generic way to detect that, I believe how activerecord handles connection pools is the same basic idea as what I need.

Let me know if that helps @jjb

[danmayer]

closing this out as there is nothing to be done

[jjb]

@danmayer thank you so much for that explanation 1.5 years ago - so sorry that i didn't respond. thanks again for maintaining this super useful project!