Issues with custom error message translations #336

elcommie · 2019-04-17T19:15:42Z

We have a model class in rails with the following validation:

  validates :items, length: {
    minimum: 1, message: I18n.t('items.one_required')
  }

This works fine in version 5.0.1, but in 5.0.2 there's a translation missing: en.items.one_required in the errors collection. Not sure why factory_bot would affect the i18n class but it appears to.

The text was updated successfully, but these errors were encountered:

composerinteralia · 2019-04-17T19:43:54Z

There was a bug in 5.0.1 that was causing the factory_bot_rails reloader to watch the project root in some cases. We fixed that in 5.0.2. This probably has something to do with that fix. This is definitely not expected behavior!

What file is your translation in?
Is the I18n reloader watching that file? (You can look at Rails.application.reloaders in the console. For me the I18n reloader is the second one in that list.) (You might also look around in https://github.com/rails/rails/blob/master/activesupport/lib/active_support/i18n_railtie.rb#L41-L74 for clues.)

I will try my best to reproduce this. Please share whatever details you can.

Thanks!

elcommie · 2019-04-17T21:01:46Z

It's in the standard config/locales/en.yml file and I see that file near the bottom of the reloaders as you'd expect.

Interestingly, I tried loading factory_bot in console and creating a record there and it worked. But in rspec it fails. Also, I tried just creating a new model that wasn't as complex as mine (my production model inherits from two different other models, uses mixins and a number of other things built up over the years) and that one worked too. Very odd. I'll see if I can narrow down the scenario that triggers this

hathcode · 2019-04-22T12:53:01Z

@composerinteralia I had the same issue come up and I think I narrowed it down to this change, though it might actually be the one mentioned above(#331 ). I'm not sure how to recommend a fix 😅 but maybe some more information:

It appears the new change is causing the suite to load_definitions before the globalization yml files are loaded. Interestingly enough, I was able to get tests successfully passing by putting a binding.pry in a factory (in which I was able to verify that the translations are not being loaded before the factory definitions are loaded), and calling FactoryBot.reload in the console, which in a hacky way loaded the I18n translations, allowing the test to succeed since the translations were then defined.

Hope this helps 😄

joshbuker · 2019-04-22T23:29:19Z

Also ran into the same error, any news on when this might be fixed?

composerinteralia · 2019-04-22T23:35:39Z

Would one of you be able to provide a sample application that reproduces the error? That would make this much easier to debug.

joshbuker · 2019-04-23T00:45:47Z

@composerinteralia Interestingly, I replicated the relevant code in a rails new application, but can't seem to reproduce the error. Not sure if that helps at all.

monfresh · 2019-06-08T22:19:04Z

@composerinteralia I'm running into this as well with this application: https://github.com/codeforamerica/ohana-api

Here is an example failing spec: https://github.com/codeforamerica/ohana-api/blob/master/spec/api/patch_organization_spec.rb#L76
Here is the presence validation with custom localized error message: https://github.com/codeforamerica/ohana-api/blob/master/app/models/organization.rb#L17
And here is the custom message defined in config/locales/en.yml:
https://github.com/codeforamerica/ohana-api/blob/master/config/locales/en.yml#L342

zuchmanski · 2019-07-02T08:45:49Z

Hey, are there any updates on the issue? I am experiencing the same bug in our project.

composerinteralia · 2019-07-12T02:49:14Z

No updates that I know of. I haven't been able to reproduce the error in the ohana-api application because I haven't been able to get it running. I think I need either a simpler application that reproduces the error, or some help getting ohana-api set up.

zuchmanski · 2019-07-12T10:00:45Z

@composerinteralia Ok, I've found a way to reproduce it in a new rails app.

https://github.com/zuchmanski/factory-bot-rails-failing-example

To reproduce please clone the repo, bundle install, rake db:schema:load and run rspec --backtrace spec/example_spec.rb.

I've found out that it only happens if you try to read translation during class loading inside the factory:

class Post < ApplicationRecord
  HELLO = I18n.t('hello')
end

FactoryBot.define do
  factory :post do
    title { 'Message' }

    # This loads a Post class, fails since translations are not loaded yet.
    # Comment this line and spec passes.
    Post::HELLO
  end
end

Full diff from empty rails app: https://github.com/zuchmanski/factory-bot-rails-failing-example/commit/2953068207b22eeb08dc00c495addb4c2dcddce0

ishigo974 · 2019-07-17T13:55:08Z

Hi, I have the same issue with a translation present in a model.

I reproduced it really quickly with this code:

class Model
  REASONS = I18n.t("enumerize.reason")
end

Whereas I had no problem before updating factory_bot_rails from 5.0.1 to 5.0.2, now I have this:

I18n::MissingTranslationData (translation missing: en.enumerize.reason)

zuchmanski · 2019-07-24T06:28:23Z

@composerinteralia

Is there anything I can do to help you? Have you been able to reproduce the behavior with my repo?

I can try working on it if you could point me the changes, files that you suspect broke the code loading logic.

rkorzeniec · 2019-07-26T14:43:17Z

I am experiencing a similar case
code:

class Model
  validates :foreign_key_id, presence: { message: I18n.t('path.to.locale') }
end

test:

it do
  is_expected.to validate_presence_of(:foreign_key_id).with_message(I18n.t('path.to.locale'))
end

error:

Expected Model to validate that :foreign_key_id cannot be
empty/falsy, producing a custom validation error on failure, but this
could not be proved.
  After setting :foreign_key_id to ‹nil›, the matcher expected the
  Model to be invalid and to produce the validation
  error "Locale translation" on :foreign_key_id. The record was indeed
  invalid, but it produced these validation errors instead:

  * foreign_key_id: ["<span class=\"translation_missing\"
    title=\"translation missing: en.path.to.locale\">Path To Locale</span>"]

composerinteralia · 2019-07-26T14:49:14Z

I have an idea about how to fix this. I will work on it a bit today and then either make a PR or post here what I have learned so far.

Fixes #336 Before this commit, the initialization process looked something like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback[], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit moves factory_bot reloading from a prepare callback into an `after_initialize` callback. This allows us to avoid reloading factory_bot before I18n is loaded, and also gets rid of that pesky double reloading of factory_bot. The new initialization process looks like: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] 2. Run the [`:run_prepare_callbacks`][] initializer, which no longer involves factory_bot Rails runs `after_intialize` callbacks 1. [I18n initializes] 2. Run the factory_bot reloader, which sets up the prepare callback for any future prepares (for example calling `reload!` in the console), and executes the reloader to run the initial `FactoryBot.reload` [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27

Fixes #336 Before this commit, the initialization process looked like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit moves factory_bot reloading from a prepare callback into an `after_initialize` callback. This allows us to avoid reloading factory_bot before I18n is loaded, and also gets rid of that pesky double reloading of factory_bot. The new initialization process looks like: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] 2. Run the [`:run_prepare_callbacks`][] initializer, which no longer involves factory_bot Rails runs `after_intialize` callbacks 1. [I18n initializes] 2. Run the factory_bot reloader, which sets up the prepare callback for any future prepares (for example calling `reload!` in the console), and executes the reloader to run the initial `FactoryBot.reload` [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27

composerinteralia · 2019-07-26T20:58:25Z

Not quite ready to merge, since I had some trouble with testing, but it would be helpful if somebody that has encountered this problem can confirm that the fix in #343 works for you.

I tried it out on the app @zuchmanski provided and it seems to have done the trick.

Fixes #336 Before this commit, the initialization process looked like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] as described in #334 The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit moves factory_bot reloading from a prepare callback into an `after_initialize` callback. This allows us to avoid reloading factory_bot before I18n is loaded, and also gets rid of that pesky double reloading of factory_bot. The new initialization process looks like: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] 2. Run the [`:run_prepare_callbacks`][] initializer, which no longer involves factory_bot Rails runs `after_intialize` callbacks 1. [I18n initializes] 2. Run the factory_bot reloader, which sets up the prepare callback for any future prepares (for example calling `reload!` in the console), and executes the reloader to run the initial `FactoryBot.reload` [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27

rkorzeniec · 2019-07-28T07:19:56Z

@composerinteralia on my setup it returned the following error:

An error occurred while loading rails_helper.
Failure/Error: require File.expand_path('../config/environment', __dir__)

NoMethodError:
  undefined method `reloader' for #<Test::Application:0x00007fdd0202a0f8>
  Did you mean?  reloaders
# ./config/environment.rb:4:in `<top (required)>'
# ./spec/rails_helper.rb:4:in `<top (required)>'

composerinteralia · 2019-07-28T07:30:08Z

Thanks for trying it out! I am also seeing that error on CI for certain versions. It seems there is more work to be done here. What version of Rails are you on?

rkorzeniec · 2019-07-28T08:03:16Z

That project is on rails 4.2.11.1

zuchmanski · 2019-07-29T07:44:02Z

Not quite ready to merge, since I had some trouble with testing, but it would be helpful if somebody that has encountered this problem can confirm that the fix in #343 works for you.

@composerinteralia I confirm that the fix works in our projects! Thanks!

monfresh · 2019-08-10T21:39:37Z

@composerinteralia I confirm it fixes the issue in ohana-api. Thanks!

Fixes #336 Alternate solution to #343 The initialization process looks like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] as described in #334 The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit changes step 4 above to avoid reloading factory_bot before the application has initialized. [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27 Co-authored-by: Danny Garcia <[email protected]>

Fixes #336 Before this commit, the initialization process looked like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] as described in #334 The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit moves factory_bot reloading from a prepare callback into an `after_initialize` callback. This allows us to avoid reloading factory_bot before I18n is loaded, and also gets rid of that pesky double reloading of factory_bot. The new initialization process looks like: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] 2. Run the [`:run_prepare_callbacks`][] initializer, which no longer involves factory_bot Rails runs `after_intialize` callbacks 1. [I18n initializes] 2. Run the factory_bot reloader, which sets up the prepare callback for any future prepares (for example calling `reload!` in the console), and executes the reloader to run the initial `FactoryBot.reload` [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27

Fixes #336 Alternate solution to #343 The initialization process looks like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] as described in #334 The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit changes step 4 above to avoid reloading factory_bot before the application has initialized. [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27 Co-authored-by: Danny Garcia <[email protected]>

malachewhiz · 2019-10-02T10:21:37Z

@composerinteralia #347 works for us (did not test #343, though)

Fixes #336 Alternate solution to #343 The initialization process looks like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] as described in #334 The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit changes step 4 above to avoid reloading factory_bot before the application has initialized. [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27 Co-authored-by: Danny Garcia <[email protected]>

Alternate fix for #336. We went with #347 instead because the solution in this commit didn't work with Rails 4.2. Since we are no longer supporting Rails 4.2, I think this is a better approach. The original problem looked like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] as described in #334 Triggering the first factory_bot reload before initializing I18n could cause an error in some cases. We avoided the problem in #347 by adding a conditional to skip reloading factory_bot before the application has initialized. This commit, on the other hand, moves factory_bot reloading from a prepare callback into an `after_initialize` callback. The initialization process is now simplified to: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] 2. Run the [`:run_prepare_callbacks`][] initializer, which no longer involves factory_bot Rails runs `after_intialize` callbacks 1. [I18n initializes] 2. factory_bot loads definitions for the first time. It then runs the reloader to set up the prepare callback to reload factory_bot when the application reloads (for example by calling `reload!` in the console), and to register the reloader to trigger reloads when any factory_bot definition files change. [set_factory_paths]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L17-L19 [register_reloader]: https://github.com/thoughtbot/factory_bot_rails/blob/3815aae2b9e4a5c5c3027a2ee8851f44b7c6a4da/lib/factory_bot_rails/railtie.rb#L21-L23 [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: https://github.com/rails/rails/blob/13e2102517fafc8f8736fce5d57de901067202d0/activesupport/lib/active_support/i18n_railtie.rb#L16-L20 [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27

composerinteralia mentioned this issue Jul 26, 2019

Set up reloading after_initialize #343

Closed

composerinteralia mentioned this issue Sep 20, 2019

Ensure factory_bot only loads after initialization #347

Merged

composerinteralia closed this as completed in #347 Oct 2, 2019

composerinteralia mentioned this issue May 22, 2020

Set up reloading after_initialize #381

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issues with custom error message translations #336

Issues with custom error message translations #336

elcommie commented Apr 17, 2019 •

edited

Loading

composerinteralia commented Apr 17, 2019 •

edited

Loading

elcommie commented Apr 17, 2019 •

edited

Loading

hathcode commented Apr 22, 2019 •

edited

Loading

joshbuker commented Apr 22, 2019

composerinteralia commented Apr 22, 2019 •

edited

Loading

joshbuker commented Apr 23, 2019

monfresh commented Jun 8, 2019

zuchmanski commented Jul 2, 2019

composerinteralia commented Jul 12, 2019

zuchmanski commented Jul 12, 2019 •

edited

Loading

ishigo974 commented Jul 17, 2019

zuchmanski commented Jul 24, 2019

rkorzeniec commented Jul 26, 2019

composerinteralia commented Jul 26, 2019

composerinteralia commented Jul 26, 2019

rkorzeniec commented Jul 28, 2019

composerinteralia commented Jul 28, 2019

rkorzeniec commented Jul 28, 2019

zuchmanski commented Jul 29, 2019 •

edited

Loading

monfresh commented Aug 10, 2019

malachewhiz commented Oct 2, 2019

Issues with custom error message translations #336

Issues with custom error message translations #336

Comments

elcommie commented Apr 17, 2019 • edited Loading

composerinteralia commented Apr 17, 2019 • edited Loading

elcommie commented Apr 17, 2019 • edited Loading

hathcode commented Apr 22, 2019 • edited Loading

joshbuker commented Apr 22, 2019

composerinteralia commented Apr 22, 2019 • edited Loading

joshbuker commented Apr 23, 2019

monfresh commented Jun 8, 2019

zuchmanski commented Jul 2, 2019

composerinteralia commented Jul 12, 2019

zuchmanski commented Jul 12, 2019 • edited Loading

ishigo974 commented Jul 17, 2019

zuchmanski commented Jul 24, 2019

rkorzeniec commented Jul 26, 2019

composerinteralia commented Jul 26, 2019

composerinteralia commented Jul 26, 2019

rkorzeniec commented Jul 28, 2019

composerinteralia commented Jul 28, 2019

rkorzeniec commented Jul 28, 2019

zuchmanski commented Jul 29, 2019 • edited Loading

monfresh commented Aug 10, 2019

malachewhiz commented Oct 2, 2019

elcommie commented Apr 17, 2019 •

edited

Loading

composerinteralia commented Apr 17, 2019 •

edited

Loading

elcommie commented Apr 17, 2019 •

edited

Loading

hathcode commented Apr 22, 2019 •

edited

Loading

composerinteralia commented Apr 22, 2019 •

edited

Loading

zuchmanski commented Jul 12, 2019 •

edited

Loading

zuchmanski commented Jul 29, 2019 •

edited

Loading