FrozenError when adding a factory called :product #303
Comments
|
No, product isn't a reserved word. I think you may be running into #247. Can you provide a backtrace, or any additional information? I haven't been able to reproduce this myself, which makes it difficult to debug. |
|
Here's the backtrace: Sorry for the font, but the included # and ` characters in the stacktrace seem to trigger Markdown... |
|
Yeah, this seems to be similar to #247. The error comes from calling insert on a frozen array here: https://github.com/rails/rails/blob/5-2-1/actionpack/lib/action_dispatch/middleware/stack.rb#L76. This error isn't pointing to anything obvious in factory_bot or factory_bot_rails. This issue on Rails also seems related: rails/rails#33745 |
|
Since there isn't anything obviously pointing to factory_bot, and there is some indication that it might have been fixed (see #247 (comment)) I'm going to close this issue for now. If you are able to share a sample app that reproduces the error, I would be happy to help debug. Thanks! |
|
Actually I think I was able to reproduce this after all! I wrote this invalid factory: Factory.define do
factory :user
factory :user
endWhen we run the test suite RSpec starts by loading every spec file. It goes something like this:
The |
|
Actually, it seems like rspec/rspec-core#2568 addressed exactly this |
jamesjefferies
added a commit
to Energy-Sparks/energy-sparks
that referenced
this issue
Mar 3, 2019
imjoehaines
added a commit
to bugsnag/bugsnag-ruby
that referenced
this issue
Jul 23, 2020
This should never happen in normal operation, but is possible when running RSpec tests See thoughtbot/factory_bot_rails#303 (comment) and #534 Essentially this happens: 1. RSpec boots Rails 2. Rails boot process errors 3. Rails freezes middleware 4. RSpec moves on to the next test file 5. Bugsnag tries to add middleware but fails because it's frozen 6. The stacktrace blames Bugsnag for this test failure 7. goto 4 Supressing this error doesn't solve the problem as it's likely another frozen error will happen in some other library/component, but we want to avoid people thinking this is caused by Bugsnag. The stacktrace does point out the actual problem, but only in the very first error, which can get buried under the frozen errors that happen for each test file
imjoehaines
added a commit
to bugsnag/bugsnag-ruby
that referenced
this issue
Jul 23, 2020
This should never happen in normal operation, but is possible when running RSpec tests See thoughtbot/factory_bot_rails#303 (comment) and #534 Essentially this happens: 1. RSpec boots Rails 2. Rails boot process errors 3. Rails freezes middleware 4. RSpec moves on to the next test file 5. Bugsnag tries to add middleware but fails because it's frozen 6. The stacktrace blames Bugsnag for this test failure 7. goto 4 Supressing this error doesn't solve the problem as it's likely another frozen error will happen in some other library/component, but we want to avoid people thinking this is caused by Bugsnag. The stacktrace does point out the actual problem, but only in the very first error, which can get buried under the frozen errors that happen for each test file
Merged
15 tasks
imjoehaines
added a commit
to bugsnag/bugsnag-ruby
that referenced
this issue
Jul 23, 2020
This should never happen in normal operation, but is possible when running RSpec tests See thoughtbot/factory_bot_rails#303 (comment) and #534 Essentially this happens: 1. RSpec boots Rails 2. Rails boot process errors 3. Rails freezes middleware 4. RSpec moves on to the next test file 5. Bugsnag tries to add middleware but fails because it's frozen 6. The stacktrace blames Bugsnag for this test failure 7. goto 4 Supressing this error doesn't solve the problem as it's likely another frozen error will happen in some other library/component, but we want to avoid people thinking this is caused by Bugsnag. The stacktrace does point out the actual problem, but only in the very first error, which can get buried under the frozen errors that happen for each test file
imjoehaines
added a commit
to bugsnag/bugsnag-ruby
that referenced
this issue
Jul 27, 2020
This should never happen in normal operation, but is possible when running RSpec tests See thoughtbot/factory_bot_rails#303 (comment) and #534 Essentially this happens: 1. RSpec boots Rails 2. Rails boot process errors 3. Rails freezes middleware 4. RSpec moves on to the next test file 5. Bugsnag tries to add middleware but fails because it's frozen 6. The stacktrace blames Bugsnag for this test failure 7. goto 4 Supressing this error doesn't solve the problem as it's likely another frozen error will happen in some other library/component, but we want to avoid people thinking this is caused by Bugsnag. The stacktrace does point out the actual problem, but only in the very first error, which can get buried under the frozen errors that happen for each test file
aeroastro
added a commit
to aeroastro/rspec-rails
that referenced
this issue
Mar 9, 2022
When there is a bug in the code on the load, RSpec catches the exception, aborts the spec file, proceeds to the following spec file, and retries `require` with partially loaded Rails application. In some cases, we see many identical errors, such as `NameError`, which are noisy but help developers find the bug. In other cases, due to retrying `require`, we see many unrelated errors like `FrozenError`, which flood the result and flush out the original cause at the top. The following comment describes this issue in detail. thoughtbot/factory_bot_rails#303 (comment) This patch prevents unrelated exceptions by the fail-fast feature of rspec/core. rspec/rspec-core#2568
aeroastro
added a commit
to aeroastro/rspec-rails
that referenced
this issue
Mar 9, 2022
When there is a bug in the code on the load, RSpec catches the exception, aborts the spec file, proceeds to the following spec file, and retries `require` with partially loaded Rails application. In some cases, we see many identical errors, such as `NameError`, which are noisy but help developers find the bug. In other cases, we see many unrelated errors, typically `FrozenError` on finalized objects, which push out the original exception raised only from the first spec. The following comment describes this issue in detail. thoughtbot/factory_bot_rails#303 (comment) This patch prevents unrelated exceptions by the fail-fast feature. rspec/rspec-core#2568
aeroastro
added a commit
to aeroastro/rspec-rails
that referenced
this issue
Mar 9, 2022
When there is a bug in the code on the load, RSpec catches the exception, aborts the spec file, proceeds to the following spec file, and retries `require` with partially loaded Rails application. In some cases, we see many identical errors, such as `NameError`, which are noisy but help developers find the bug. In other cases, we see many unrelated errors, typically `FrozenError` on finalized objects, which push out the original exception raised only from the first spec. The following comment describes this issue in detail. thoughtbot/factory_bot_rails#303 (comment) This patch prevents unrelated exceptions by the following rspec-core feature. rspec/rspec-core#2568
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Rails 5.2.1, and FactoryGirl 4.8.0 (factory_girl_rails same version), I copied an existing factory called :product_spec and renamed it :product.
After doing that, the specs won't run. I get this error on every spec file:
The contents of the factory don't matter -- if I completely empty the factory, I still get the error. If I rename the factory to :product1, the error goes away. Whether or not the class name is passed doesn't make a difference. It appears :product is some kind of reserved word in factory_girl?
Code that fails:
factory :product, class: Product do
#
end
The text was updated successfully, but these errors were encountered: