Including url_helpers in class causes error

[jgadbois]

I'm including url_helpers in a class and am getting the following error:

stack level too deep
actionpack (3.1.0) lib/action_dispatch/middleware/reloader.rb:73

My include is as follows:

include Rails.application.routes.url_helpers

This worked in rails 3.0. I've also tried including the UrlFor module. The class is a PORO in app/models.

[kenmazaika]

I tried to create a test in rails that caused this problem. I could not. I figured it could be fixed in edge, or I could be mocking things out incorrectly.

I ended up creating a new Rails 3.1.0 app and tried to reproduce the issue. It looks like it isn't a problem.

https://github.com/kenmazaika/test_app/blob/master/test/unit/simple_class_test.rb

That test passes fine on my machine with rails 3.1.0.

Is there a chance you're doing something like:

def hello_url
hello_url
end

??

Can you reproduce this issue in a test repo like this?

[jgadbois]

I think it might be because of some other things loaded in the Rails environment?

Try this in console:

Loading production environment (Rails 3.1.0)
irb(main):001:0> include ActionView::Helpers::UrlHelper
=> Object
irb(main):002:0> include Rails.application.routes.url_helpers
=> Object
irb(main):003:0> polymorphic_path(User.find(1))
User Load (4.6ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]]
SystemStackError: stack level too deep
from /usr/local/lib/ruby/1.9.1/irb/workspace.rb:80
Maybe IRB bug!!

[kenmazaika]

I don't think this is a bug in IRB. Will you modify my test project to reproduce the error or post our routes.rb and user.rb files?

[jgadbois]

Sorry - that was part of the output I copy/pasted - I'm not saying it was bug in IRB. Just showing you how to reproduce the exception. include those two modules and call polymorphic_path.

[kenmazaika]

In response to your question:

I think it might be because of some other things loaded in the Rails environment?

Yes. I think it's caused by the user.rb file that is loaded in your environment. I think there is a bug in that code or it's doing something that it isn't allowed to that is not documented.

[jgadbois]

In this case I called user.rb - the same thing happens no matter what model I load.

[ascruggs]

I am experiencing the exact same problem. While I try to track it down, I wanted to post my Gemfile: https://gist.github.com/1294166 . Perhaps if others do the same we can target an offending external library quicker.

[ghost]

I'm having a similar issue too. No idea how to get rid of it. Often times, it will only happen on the 2nd request I do (while in development mode).

[ascruggs]

I have alleviated the problem in my app, but am not sure specifically what was causing it. I do not think that url_helpers are the root problem, just another symptom.

I put some debugging code in the reloader middleware and saw that it was the controller callbacks that were causing these errors to occur (possibly a circular loop in the callback stack?). The callbacks code uses a lot of meta-programming and debugging of the root problem fell down there.

That being said, the controller that was causing this error was inheriting from two other controllers between it and the ApplicationController. These parent controllers are used to share *_filters and associated private methods. Imagine:

RealRoutedController --> SharedSiteAdminController --> SharedAdminController --> ApplicationController

While this seemed like a good idea at the time, I think that using modules is a better approach. So, I changed it to:

RealRoutedController --> ApplicationController

Where The RealRoutedController had modules included to capture shared logic.

This alleviated the problem entirely for me. YMMV, but if you are doing anything past vanilla filters you may want to explore was to refactor them.

[rafaldyrda]

I have a similar issue, but whenever I have a scope in a model..

[sinisterchipmunk]

Another piece of the puzzle.

My controller is just a scaffold, as Rails generated it.

My model is entirely hand-crafted though, wrapping ActiveModel.

I read this:

if you are doing anything past vanilla filters you may want to explore was to refactor them

which reminded me that my model looked like this (and rspec was green):

extend ActiveModel::Naming
extend ActiveModel::Callbacks
include ActiveModel::Validations
include ActiveModel::Dirty
include ActiveModel::Conversion
define_model_callbacks :save, :create, :update, :initialize, :destroy, :validation

alias _valid? valid?
def valid?
  valid = false
  run_callbacks(:validation) { valid = _valid? }
  valid
end

# ...

(In my defense, I knew it was a hack when I wrote it, but the specs didn't pass beforehand, so I assumed ActiveModel::Validations doesn't run callbacks....)

I took the overriden valid? method out, and the issue went away! Digging deeper, I now see that ActiveModel::Validations calls #run_callbacks (oops!) and I should have just included ActiveModel::Validations::Callbacks. Doing so removes the hack, makes the specs green, and removes the stack trace error in my case.

Alas, dropping the offending code into a fresh Rails app did not reproduce the issue, but hopefully this extra info will be helpful in tracking down the real problem.

[akarpenko]

Had the same issue, but updating gems with "bundle update" fixed it...

[elsurudo]

I had this problem, too. Got around it by calling the helpers directly from my model, like so:

Rails.application.routes.url_helpers.users_url

The problem still exists, though...

[pixeltrix]

Closing this as I can't reproduce it - the stack level too deep message is usually an indication of recursion, so something like a method name collision is probably the cause. If someone can either do a simple steps to repeat or create a repo that reproduces the error I'll reopen it and take a look.

[gerwitz]

Like @elsurudo I had this problem (in a model) and traced it to the include. Fixed by directly referencing Rails.application.routes.url_helpers.

Just a datapoint, I do not yet have a reproduction to share for reopening.

[steveklabnik]

@gerwitz use backticks instead of underscores when referencing code, I got real confused reading your comment. ;) I've edited it.

[steveklabnik]

Whoah, sorry for thread necromancy. I opened all my github emails from my email, no idea why it linked here.

[shadowmaru]

I was having this problem, when migrating from 3.0 to 3.1, when running any rake task.

To reproduce, follow the steps

• rails _3.1.10_ new example
• add a .rake file in lib/tasks containing only include ActionView::Helpers::ControllerHelper
• run bundle exec rake routes, bundle exec rake about or any rake task for that matter

You may run into the same problem with Rails 3.2.x

More details here:

http://stackoverflow.com/questions/14739515/stack-level-too-deep-error-when-running-any-rake-task

Can this issue be reopened?

[mpolakis]

I just faced this issue in 3.2.14, so it's there.

[h0jeZvgoxFepBQ2C]

I also get this when I try to use the url_helpers in minitest:

# test_helper.rb (with using minitest-rails)
class ActionMailer::TestCase
  include Rails.application.routes.url_helpers
  register_spec_type(/Mailer( ?Test)?\z/i, self)
end

[robin850]

Sorry guys, I'm reopening this since @shadowmaru gave a way to reproduce this and following the steps, I got the "stack level too deep" error (on master and 4.0.1 apps).

[pixeltrix]

What's the use case for including ActionView::Helpers::ControllerHelper into the top level namespace?

[sandipransing]

I am able to reproduce this issue. If you include ActionView::Helpers::ControllerHelper outside of rake task then stack level too deep exception is raised.

[carlosantoniodasilva]

@sandipransing can you post the code that reproduces it?

[sandipransing]

@carlosantoniodasilva

Create some rake file and add include ActionView::Helpers::ControllerHelper to it. make sure it is placed outside of actual task block.

# lib/tasks/test.rake
include ActionView::Helpers::ControllerHelper

Now if you try to run rake -T it works but rake routes fails with following error:

$ rake routes
rake aborted!
stack level too deep

Tasks: TOP => routes => environment
(See full trace by running task with --trace)

$

[sandipransing]

@carlosantoniodasilva
Test case is added to reproduce the same
#13801

[carlosantoniodasilva]

I see.. now, why would you include the helper in the top level? And also, which version are you testing against.

[sandipransing]

@carlosantoniodasilva i am testing against edge rails.

[rafaelfranca]

The question remains. why would you include the helper in the top level?

[shadowmaru]

@carlosantoniodasilva @rafaelfranca

My case was that I had to include another helper (ActionView::Helpers::TextHelper). I included the parent module (ActionView::Helpers) so I could have access to other helpers (let's say ActionView::Helpers::NumberHelper) and also in other tasks.

The issue (stack level too deep) is specific to ActionView::Helpers::ControllerHelper, but other people might run into the same problem, and spend a great deal of time debugging it (as I did).

[rafaelfranca]

This issue has been automatically marked as stale because it has not been commented on for at least
three months.

The resources of the Rails team are limited, and so we are asking for your help.

If you can still reproduce this error on the 4-1-stable, 4-0-stable branches or on master,
please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions.

[rails-bot]

This issue has been automatically closed because of inactivity.

If you can still reproduce this error on the 4-1-stable, 4-0-stable branches or on master,
please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions.