[Bug] Concurrency issues about business_time HOT 6 CLOSED

Hey! I'll get back to you tomorrow, however:

1. Yes I am aware, but when they are forked the config is lost.
2. You are right, my bad on the correct date.
3. It's a hit or miss, depending on the process. I will re-test tomorrow and try to come up with something beter for testing.

from business_time.

Btw, now that I know this, I realize what happened back here: #206 so I am closing it.

from business_time.

I'm a tad confused by this report for multiple reasons:

1. Puma workers are processes, not threads.
2. The correct date for your scenario is June 1, 2021, not April 1.

   >> BusinessTime::Config.holidays << '2021-05-31'.to_date
   => #<Set: {Mon, 31 May 2021}>
   >> 1.business_day.after('2021-05-28'.to_date)
   => Tue, 01 Jun 2021

3. I cannot reproduce your scenario using puma workers, even if it is related to the puma worker boot. Are you sure you performed a full restart of the application during your testing?

from business_time.

Thanks. A simple app that reproduces the issue would be much appreciated. Either way, this sounds like an issue outside of this gem, but it might be helpful in a README.

from business_time.

@rmm5t well, this has been eye opening. I wasn't able to replicate in the new minimal test app and I figured out what was happening. I thank you for your time.

So, what was happening is, at some point we started using some experimental options, specifically, fork_worker is the culprit.

I'm closing this and sorry for the time spent.

from business_time.

@pmcnano No worries. Thanks for the follow-up.

from business_time.