Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getting FrozenError: can't modify frozen Array: when running specs #335

Closed
Jakanapes opened this issue Jul 18, 2024 · 8 comments
Closed

Comments

@Jakanapes
Copy link

working to replace paranoia with acts_as_paranoid

swapped out the gems

trying to run specs and receiving
FrozenError:
can't modify frozen Array:

for the autoload paths

# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/engine.rb:580:in `unshift'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/engine.rb:580:in `block in <class:Engine>'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:32:in `instance_exec'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:32:in `run'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:61:in `block in run_initializers'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:50:in `each'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:50:in `tsort_each_child'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:50:in `each'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:50:in `tsort_each_child'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/initializable.rb:60:in `run_initializers'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/railties-7.1.3.4/lib/rails/application.rb:426:in `initialize!'
# ./config/environment.rb:7:in `<top (required)>'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/zeitwerk-2.6.15/lib/zeitwerk/kernel.rb:34:in `require'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/zeitwerk-2.6.15/lib/zeitwerk/kernel.rb:34:in `require'
# ./spec/spec_helper.rb:23:in `<top (required)>'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/zeitwerk-2.6.15/lib/zeitwerk/kernel.rb:34:in `require'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/zeitwerk-2.6.15/lib/zeitwerk/kernel.rb:34:in `require'
# ./spec/rails_helper.rb:3:in `<top (required)>'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/zeitwerk-2.6.15/lib/zeitwerk/kernel.rb:34:in `require'
# /Users/jakanapes/.gem/ruby/3.2.2/gems/zeitwerk-2.6.15/lib/zeitwerk/kernel.rb:34:in `require'
# ./spec/models/user_spec.rb:3:in `<top (required)>'

going over the gem source, nothing is freezing the array explicitly. Need to dig into what's happening internally in rails in the ActiveSupport.on_load block, though. Any thoughts?

@mvz
Copy link
Contributor

mvz commented Jul 18, 2024

The can't modify frozen Array error tends to happen with rspec whenever something early in the spec process fails. Can you try running bundle exec rspec spec/models/user_spec.rb and see what error you get?

@Jakanapes
Copy link
Author

aha, rogue before_real_destroy, I jumped straight to looking at Rails internals.

There is not an equivalent callback for the real destroy, correct?

@mvz
Copy link
Contributor

mvz commented Jul 19, 2024

No, acts_as_paranoid does not have that callback.

@Jakanapes
Copy link
Author

Doesn't look like there's a way built into the gem where I can determine if it's a soft or hard delete in the method called by the callback, unless I'm missing it?

I have several use cases where I need different behavior in the callback based on soft or hard delete.

@mvz
Copy link
Contributor

mvz commented Jul 19, 2024

No there is no built in way for that. If you first soft-delete and then hard-delete, the second time the callback is called self.destroyed? will be true, but that's only if you first do the soft-delete. If you hard-delete immediately, self.destroyed? will be false in the callback.

By the way, why are you moving away from paranoia?

@Jakanapes
Copy link
Author

"Paranoia will continue to accept bug fixes and support new versions of Rails but isn't accepting new features."

from their GH page.

it already fails on the beta versions of Rails 7.2 and while the maintainers say they'll support new versions of Rails, I have no idea how long that'll take or how long it'll be true.

@mvz
Copy link
Contributor

mvz commented Jul 19, 2024

Since acts_as_paranoid is subtly different from paranoia in lots of ways, this could be a painful migration. I don't read the text in the README as saying paranoia is neglected. Rails 7.1 support was added 6 days after the release of Rails 7.1, so that's pretty quick. The text in the README was added 7 years ago, so the support promise seems pretty solid.

@Jakanapes
Copy link
Author

You were spot on, they just released a new version a few days ago with support for the 7.2 beta.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants