Roadie::CSSFileNotFound with Rails 3.2/roadie 2.3.0.pre1

[mange]

Roadie::CSSFileNotFound with Rails 3.2/roadie 2.3.0.pre1

[mareczek]

Dive into your console, to the "staging" env and check this:

Roadie.app is exactly the same as Rails.application, but you can check both just to be on the safe side.

If Roadie.app.assets.path doesn't list '/public/assets' in which are the compiled assets then you have your answer.

[Mange]

I would like to know if that is the case, and if it is, what paths are present instead?

[wgrrrr]

Here's the output of Roadie.app.assets.paths

=> ["/home/fhapp/app/releases/20120124060417/app/assets/images",
"/home/fhapp/app/releases/20120124060417/app/assets/javascripts",
"/home/fhapp/app/releases/20120124060417/app/assets/stylesheets",
"/home/fhapp/app/releases/20120124060417/vendor/assets/javascripts",
"/home/fhapp/app/releases/20120124060417/vendor/assets/stylesheets", 
"/home/fhapp/app/shared/bundle/ruby/1.9.1/gems/jquery-rails-2.0.0/vendor/assets/javascripts",
"/home/fhapp/app/shared/bundle/ruby/1.9.1/gems/client_side_validations-3.1.4/vendor/assets/javascripts"]

No '/public/assets' to be found. Just out of curiosity, here's the output of [AppName].assets.paths

=> ["/home/fhapp/app/releases/20120124060417/app/assets/images",
"/home/fhapp/app/releases/20120124060417/app/assets/javascripts",
"/home/fhapp/app/releases/20120124060417/app/assets/stylesheets",
"/home/fhapp/app/releases/20120124060417/vendor/assets/javascripts",
"/home/fhapp/app/releases/20120124060417/vendor/assets/stylesheets", 
"/home/fhapp/app/shared/bundle/ruby/1.9.1/gems/jquery-rails-2.0.0/vendor/assets/javascripts",
"/home/fhapp/app/shared/bundle/ruby/1.9.1/gems/client_side_validations-3.1.4/vendor/assets/javascripts"]

[wgrrrr]

I just completely deleted the Roadie gem (including the cache) and reinstalled to rule that out: no change. Here is a full backtrace of the exception:

Roadie::CSSFileNotFound: Could not find email-49a1a20a64caf9a4b757cac2fe2733e6.css
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/asset_pipeline_provider.rb:24:in `block in asset_file'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/asset_pipeline_provider.rb:23:in `tap'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/asset_pipeline_provider.rb:23:in `asset_file'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/asset_pipeline_provider.rb:13:in `find'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:102:in `block in extract_link_elements'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:101:in `each'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:101:in `extract_link_elements'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:50:in `block in execute'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:75:in `block in adjust_html'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:74:in `tap'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:74:in `adjust_html'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/inliner.rb:47:in `execute'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie.rb:6:in `inline_css'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/action_mailer_extensions.rb:42:in `inline_style_response'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/action_mailer_extensions.rb:32:in `block in collect_responses_and_parts_order_with_inline_styles'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/roadie-2.3.0.pre1/lib/roadie/action_mailer_extensions.rb:32:in `map'
... 27 levels...
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/validations.rb:50:in `save'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/attribute_methods/dirty.rb:22:in `save'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/transactions.rb:241:in `block (2 levels) in save'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/transactions.rb:295:in `block in with_transaction_returning_status'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/connection_adapters/abstract/database_statements.rb:190:in `transaction'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/transactions.rb:208:in `transaction'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/transactions.rb:293:in `with_transaction_returning_status'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/transactions.rb:241:in `block in save'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/transactions.rb:252:in `rollback_active_record_state!'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/activerecord-3.2.0/lib/active_record/transactions.rb:240:in `save'
    from (irb):12
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.0/lib/rails/commands/console.rb:47:in `start'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.0/lib/rails/commands/console.rb:8:in `start'
    from /home/fhapp/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.0/lib/rails/commands.rb:41:in `<top (required)>'

[Mange]

That's so strange. I mean, /home/fhapp/app/releases/20120124060417/app/assets/stylesheets + email-49a1a20a64caf9a4b757cac2fe2733e6.css should exist on disk.

What happens when you try the following in the console?

irb> YourApp.assets['email.css']

[wgrrrr]

The output of YourApp.assets['email.css'] is

=> #<Sprockets::BundledAsset:0x169bcb0 pathname="/home/fhapp/app/releases/20120124175630/app/assets/stylesheets/email.css.scss", mtime=2012-01-17 11:11:07 -0700, digest="49a1a20a64caf9a4b757cac2fe2733e6">

But the file email-49a1a20a64caf9a4b757cac2fe2733e6.css does not exist in /home/fhapp/app/releases/20120124060417/app/assets/stylesheets. There seems to be some mix up between where Roadie is expecting to find the compiled assets. It seems to be looking into the source directories instead of public/assets (which is where the compiled CSS is). It should be noted that the rest of the application works as expected (it finds the compiled assets correctly).

I'm pretty new to Rails so hopefully this makes sense. Thanks so much for your help!

[mareczek]

In you asset.pats you don't have the public assets dir. Go to config/application.rb and add the line Rails.application.assets.path << Rails.root.join 'public', 'assets'
After that deploy with capistrano and should be ok.

[wgrrrr]

I understand that's what you did as a workaround, but that doesn't seem to actually fix the root cause. Nothing has changed in my app other than an upgrade to Rails 3.2 and Roadie 2.3.0.pre1. Adding the public dir to the assets path doesn't explain why it worked before and why it works now for everything other than Roadie.

[wgrrrr]

FYI: Whenever I try to add to add the public/assets directory the assets.paths I get the following exception:

NoMethodError: undefined method `ends_with?' for #<Pathname:/Users/{username}/Development/fhapp/public/assets>

I get this both locally and in staging.

[mareczek]

If you're getting such exception that means that you eventually didn't add 'public/assets' to assets.path. If you would have added the path your problem would be resolved.

[wgrrrr]

Maybe I'm misunderstanding something, but whenever I attempt to add another path to the assets.paths I get the exception I mentioned above.

And even if it worked, it still wouldn't be the correct answer IMO. My configuration worked before I upgraded to Rails 3.2 and Roadie 2.3.0.pre1 - and those were the only things I changed.

[Mange]

Yeah, seems to be a real problem from my side.

I'll check out to see if I'm interfacing Sprockets correctly.

[Mange]

Ah, I think I get it now!

The rendered HTML has a tag like this:

  <link rel="stylesheet" href="/assets/email-sha.js" type="text/css" />

This causes Roadie to look for an asset named email-sha.js, even though the real asset is named email.js. The logical names should be given, not the generated names.

I'm not sure which way would be best to fix this, actually. Here are two ideas:

• AssetPipelineProvider could try to filter out what it believes to be SHAs when an asset cannot be found and try again
• Roadie could perhaps have multiple providers in a chain and try them each - first assets, then filesystem

Anyone of you want to help me decide on the approach?

In the mean time, @wgrrrr, here are some workarounds to get your app up and running again; pick one:

• Change from AssetPipelineProvider to FilesystemProvider in your production environment
• Generate the <link /> element yourself, making it point to just assets/email.css instead of using the "correct" asset path

[wgrrrr]

Exactly @Mange, the rendered asset tag is as you specified (except it's CSS not JS - I think you meant CSS).

I believe that when the Asset Pipeline is enabled Roadie should definitely look for compiled assets in the public/assets directory. This allows people to use Sass, Less, etc. inside of their email.css. If you just look for uncompiled assets they aren't going work (if using Sass/Less/etc.), or dev's will not be able to use those facilities.

Thanks for your suggestions! Take care.

[Mange]

except it's CSS not JS - I think you meant CSS

Indeed.

If you just look for uncompiled assets they aren't going work (if using Sass/Less/etc.), or dev's will not be able to use those facilities.

The Asset Pipeline compiles them for us if they aren't compiled. Problems occur when the current environment is using precompiled assets instead of compiling on the fly.

I'm going to try to make the provider a bit smarter and see if I can make it work with them as well.

[wgrrrr]

Hmmm... the default in production environments for >Rails 3.1 is to precompile assets. Are you saying that people need to disable precompiling and enable compile on-the-fly? I had Roadie working with precompiled assets before my 3.2 upgrade... seemed to work fine.

[Mange]

No, that's just a temporary work-around until I get this fixed. Roadie need to look for precompiled assets on the filesystem while still fetching non-compiled assets from the asset pipeline.

It's a bit strange that it worked before. There was no code in place to handle precompiled assets. Perhaps your view changed?

[Mange]

Workaround is now mentioned in the README as a "Note:".
I'll move to fix this in the next release.

[moll]

Just for anyone trying to get Roadie working with precompiled assets (based on what @Mange said):

# config/environments/production.rb:
Monday::Application.configure do
  config.roadie.provider = Roadie::FilesystemProvider.new(Rails.root, "public")
end

# app/views/layouts/mailer.html:
<link rel='stylesheet' type='text/css' href='/assets/email.css'>

[schiza]

@moll this is a fix, but the config should be:

config.roadie.provider = Roadie::FilesystemProvider.new("", Rails.root.join("public"))

and the link path shouldn't be with preceeding / (BTW as for me, it shouldn't matter):

<link rel='stylesheet' type='text/css' href='assets/email.css'>

[moll]

@schiza From looking at the code, IIRC, the two ways to init FilesystemProvider are equivalent. Why do you recommend one over the other?

Btw, I find the prefixed link path version to be more semantically correct, at least, because the assets live at the root of public.

[schiza]

Maybe I was too hasty, but I had some problems with both of these things, even if they looked right, after looking at the code. Maybe my misspelling, but maybe it will help someone..

[Mange]

Let me explain the prefix that can be passed since it's a bit confusing. (It's actually somewhat inherited legacy at this point, and I too need to read the source code to explain it)

The prefix is automatically removed from the URLs it encounters when it tries to match to disk. The purpose is to be able to say that all stylesheets live in <root>/public/stylesheets but still being able to find files referenced from <link> element with the URL /stylesheets/foo.css.

The normal way you should use this is by initializing it like this:

config.roadie.provider = Roadie::FilesystemProvider.new('/assets', Rails.root.join('public', 'assets'))

But once again, I cannot stress this enough: It's much, much, much more simpler if you just tell Roadie which stylesheet to use from the Mailer. Relying on Roadie correctly guessing where your stylesheet is will never be bulletproof. This is how I do it, and I really recommend it.

class Notifier < ActionMailer::Base
  defaults css: 'email'
end

I am working (albeit slowly) on a fix for this. It's going to be the next minor version since it will break backwards compatibility with this version when it comes to configure the providers. It will also add a new provider that just tries multiple providers in order until an asset is found.
It will take some time still since I have a hard time finding the time on my lunch breaks to keep working on it, but it will get there.

[zhangbanger]

This error just suddenly appeared on me. Am I understanding correctly that Roadie needs a special provider that looks in assets and public/assets?

[moll]

@zhangbanger For a [quick] fix, check out my instructions above.

[zhangbanger]

@moll Apologies, found the error:

I was using BOTH stylesheet_link_tag AND default css: 'user_mailer'

Apparently, stylesheet_link_tag was working fine in development, but caused production breakage.

[Mange]

Either do <link rel="stylesheet"> with the custom provider, or use the normal css option in the mailer and omit the <link> element in the view.

[Mange]

Problems like these should be fixed in roadie-rails version 1.0.0.