-
Notifications
You must be signed in to change notification settings - Fork 330
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
Can't load turbo-rails without Action Cable starting in Rails 7.1.2 #512
Comments
cc @fxn |
ACK. This gem supports Rails 6.0, need to think about a patch that works for both autoloaders. The root problem here is an inconsistency between the In case it helps urgently, in Rails 7.1 you can throw this in an application initializer: Rails.autoloaders.once.do_not_eager_load("#{Turbo::Engine.root}/app/channels") off the top of my head. It's near 1 AM over here. |
Not urgent! Let me know if there is anything I can do to help. For now, I am working around the issue by loading Action Cable: # config/application.rb
require "action_cable/engine" |
dupe |
@zarqman actually, shared a one-liner above that is a bit simpler. |
@fxn, ack, missed that! Thanks! |
@fxn I ran into this issue, too, and I confirm that your workaround above works. Thank you! I'm curious. I had this on the CI but not in the local environment, running on identical versions. Can these loading issues be architecture-dependent? |
@xymbol this is because, by default, Rails enables eager loading in CI test environments, but not local test environments. See config.eager_load = ENV["CI"].present? |
@mattbrictson TIL, thank you. |
The CI test pipeline breaks for Rails 7.1. The eager loading results into a Zeitwerk error in the turbo-rails gem. The current solution is to include actioncable if the application is running in a Github Action until this bug fixed. Ref: hotwired/turbo-rails#512
The CI test pipeline breaks for Rails 7.1. The eager loading results into a Zeitwerk error in the turbo-rails gem. The current solution is to include actioncable if the application is running in a Github Action until this bug is fixed. Ref: hotwired/turbo-rails#512
The CI test pipeline breaks for Rails 7.1. The eager loading results into a Zeitwerk error in the turbo-rails gem. The current solution is to include actioncable if the application is running in a Github Action until this bug is fixed. Ref: hotwired/turbo-rails#512
The CI test pipeline breaks for Rails 7.1. The eager loading results into a Zeitwerk error in the turbo-rails gem. The current solution is to include actioncable if the application is running in a Github Action until this bug is fixed. Ref: hotwired/turbo-rails#512 (cherry picked from commit 8fe1bb3)
* Upgrade Rails gem to 7.1.2 * Updates to configuration files * Add new migrations * Update turbo-rails dependencies * Require action_cable/engine hotwired/turbo-rails#512 (comment) * Remove ActiveStorageAttachment factory and modify specs * Source_file must have an active_storage_attachment so remove specs that imply otherwise * Remove duplicate key for national_standards_type in occupation_standard index * Fix request specs related to admin routing * Add spec to confirm source_file is persisted * Use more concise fixture_file_upload * Move creating of source_files to standards import model * Remove unneeded active_storage_blobs factory; minor change to source_file factory * Remove sample Stimulus hello_controller
turbo-rails (for now) does not work in Rails 7.1 without Action Cable loaded: hotwired/turbo-rails#512
This can be reverted when the following issue is fixed: hotwired/turbo-rails#512
Workaround for hotwired/turbo-rails#512
It is required by turbo-rails. See hotwired/turbo-rails#512
it is a test dependency of turbo-rails. See hotwired/turbo-rails#512
What's the status of this? Do we still need the workaround? |
@dorianmariecom totally forgot about this ticket, I'll write back! |
The issue is still there in my CI probably because of |
@dorianmariecom The issue happens when eager loading is enabled, Action Cable is not loaded, and Rails is 7.1.2 or above. I wrote a fix for this in November (#513), but in late January the PR was closed accidentally. I did a cleanup of repos and did not realize that was still not merged (I do not have commit bit in Hotwire). I have created another PR with the fix (#601). |
@fxn thx you rock, and yeah I was wondering why the previous pull request was closed |
Thanks @dhh <3 |
@fxn Thanks a lot for the fix, I've just has the same error and realised that is because there is not any new release so I've created a PR. Hope this helps 🙏 |
Even if these aren't being used, it turns out that turbo-rails still tries to autoload them in production. See: * hotwired/turbo-rails#478 * hotwired/turbo-rails#512 There's a workaround for the ActionCable issue but not for the ActiveJob one, so we just relent and require them.
Even if these aren't being used, it turns out that turbo-rails still tries to autoload them in production. See: * hotwired/turbo-rails#478 * hotwired/turbo-rails#512 There's a workaround for the ActionCable issue but not for the ActiveJob one, so we just relent and require them.
it is a test dependency of turbo-rails. See hotwired/turbo-rails#512
it is a test dependency of turbo-rails. See hotwired/turbo-rails#512
it is a test dependency of turbo-rails. See hotwired/turbo-rails#512
Similar to: hotwired/turbo-rails#512
I'm not sure whether to report this bug here, or in Rails. Let me know if I should move it.
With today's release of Rails 7.1.2, it is no longer possible to use turbo-rails without Action Cable. I get the following error when eager loading is enabled:
This check in the turbo-rails engine is supposed to automatically remove
app/channels
from the eager-load paths when Action Cable is not present:turbo-rails/lib/turbo/engine.rb
Lines 18 to 20 in e44b6a9
However, starting with Rails 7.1.2, this technique apparently no longer works.
There were changes in Rails 7.1.2 regarding auto/eager loading of paths in engines (see rails/rails#49636), so this could be a new bug Rails, or it could mean that turbo-rails needs to be changed to accommodate the new behavior.
Edit: I confirmed that rolling back rails/rails#49636 fixes the problem.
The text was updated successfully, but these errors were encountered: