No configuration required per thread (compatibility with timeliness 0.4.0+ about validates_timeliness HOT 7 OPEN

Thanks @timdiggins . Given you are loading the initializer explicitly I wonder if you are actually booting rails for these specs such the railties are loaded?

The necessary step happens in the Railtie here

from validates_timeliness.

Hi @adzap The (re)loading of the initializer only happens after the specs-- it's to stop the specs from messing up with any others (in my full suite). I can remove it and it still runs...

These lines prove the initializer is running:

    expect(Timeliness.parse(eu_date)).not_to be_nil
    expect(Timeliness.parse(us_date)).to be_nil

The spec fails during Thread.join.

I've put some debugging lines into my initializer and also the railtie (within validates_timeliness.initialize_timeliness_ambiguous_date_format) e.g.:

p(at: "config/initializers/validates_timeliness.rb (end)", current_date_format: Timeliness::Definitions.current_date_format, ambiguous_date_format: Timeliness.configuration.ambiguous_date_format)

The output indicates that the railtie is running before. (This happens both in the specs, but also when I run rails s)

{:at=>"in validates_timeliness.initialize_timeliness_ambiguous_date_format (before)", :current_date_format=>:us, :ambiguous_date_format=>:us}
{:at=>"in validates_timeliness.initialize_timeliness_ambiguous_date_format (after)", :current_date_format=>:us, :ambiguous_date_format=>:us}
{:at=>"config/initializers/validates_timeliness.rb (start)", :current_date_format=>:us, :ambiguous_date_format=>:us}
{:at=>"config/initializers/validates_timeliness.rb (end)", :current_date_format=>:euro, :ambiguous_date_format=>:us}

So is it possible that "engines_blank_point" is a better spot for hooking into than "load_config_initializers" (maybe the .after is not being respected?)
https://guides.rubyonrails.org/v5.2/configuring.html

from validates_timeliness.

Hmmm, weird. Even engines_blank_point is giving me the same ordered output. I can get the correct ordering only by changing it from an initializer block to a config.to_prepare block.

Maybe I should check that I can reproduce this in a vanilla rails project. Will share with you if I can (but won't be for a few days)

from validates_timeliness.

@timdiggins how did you go with this? was it confirmed in vanilla Rails?

from validates_timeliness.

@adzap I hadn't tried this out in vanilla rails, but I have now:

timdiggins/validates-timeliness-issue-187@8d35a60

Still failing -- is there some flaw in my spec or config?

from validates_timeliness.

Do you mind trying again against master? I changed the 'load_config_initializers' to symbol. I think I've run into this in the past. I will add a spec for this later.

from validates_timeliness.

@adzap yes looks like master fixes this.

https://github.com/timdiggins/validates-timeliness-issue-187/blob/master/spec/lib/validates_timeliness_spec.rb

from validates_timeliness.