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

Already on GitHub? Sign in to your account

Formtastic::UnknownInputError: Unable to find input class StringInput #911

Closed
vfilesgroup opened this Issue Jan 15, 2013 · 12 comments

Comments

Projects
None yet
7 participants

Hi there,

From time to time on our heroku deployed app we see this error (sometimes with TextInput, too). Restarting the dynos fixes it for a while, but it would be nice to get to the bottom of this. Has anyone else seen this, or have a fix for it?

Thanks!

Owner

justinfrench commented Jul 4, 2013

Closing due to a lack of activity.

scarver2 commented May 7, 2014

I have encountered this StringInput error randomly since January 2014.

= semantic_form_for 'user', url: sessions_path do |f|
  = f.inputs do
    = f.input :login
    = f.input :password
  = f.actions do
    = f.button t('links.login'), class: 'button', data: { disable_with: 'Loading...' }

Here is the error log: https://gist.github.com/scarver2/eeb9cb13b6f7850456d8

xlymian commented May 20, 2015

We are encountering the same issue sometimes with BooleanInput, but more often with HiddenInput. Here is small log extract:

2015-05-18T11:45:12.629297+00:00 app[web.3]: ActionView::Template::Error (Unable to find input class HiddenInput):
2015-05-18T11:45:12.629299+00:00 app[web.3]:     13:     = semantic_form_for Problem.new(current_user, params, request.original_url) do |f|
2015-05-18T11:45:12.629301+00:00 app[web.3]:     14:       = f.semantic_errors
2015-05-18T11:45:12.629303+00:00 app[web.3]:     15:       = f.inputs do
2015-05-18T11:45:12.629305+00:00 app[web.3]:     16:         = f.input :controller_name, as: :hidden
2015-05-18T11:45:12.629306+00:00 app[web.3]:     17:         = f.input :action_name, as: :hidden
2015-05-18T11:45:12.629308+00:00 app[web.3]:     18:         = f.input :current_user_id, as: :hidden
2015-05-18T11:45:12.629310+00:00 app[web.3]:     19:         = f.input :params, as: :hidden
2015-05-18T11:45:12.629312+00:00 app[web.3]:   app/views/problems/_new.html.haml:16:in `block (2 levels) in _app_views_problems__new_html_haml__3493347280847073492_69899255027720'
2015-05-18T11:45:12.629314+00:00 app[web.3]:   app/views/problems/_new.html.haml:15:in `block in _app_views_problems__new_html_haml__3493347280847073492_69899255027720'
2015-05-18T11:45:12.629316+00:00 app[web.3]:   app/views/problems/_new.html.haml:13:in `_app_views_problems__new_html_haml__3493347280847073492_69899255027720'
2015-05-18T11:45:12.629318+00:00 app[web.3]:   app/views/layouts/application.html.haml:36:in `_app_views_layouts_application_html_haml___2941546639304470306_69899344274000'

@justinfrench justinfrench reopened this May 21, 2015

Owner

justinfrench commented May 21, 2015

@scarver2 @xlymian Could you both please provide details about the platform, ruby versions, rails versions and anything else you can think of (AcrtiveAdmin? Haml?) that might help us find some commonalities?

@justinfrench I have not seen this behavior in several months. At the time we were running Rails 4.0.4 and Ruby 2.0.x, Haml 4.0.5. We are now running Rails 4.1.10, Ruby 2.2.2, Haml 4.0.6 without incident.

xlymian commented May 21, 2015

We are running on heroku Cedar cedar-10 stack with ruby ruby 2.1.0, rails 4.0.5, haml 4.1.0.beta.1, rails_admin 0.6.2. Would upgrading to rails 4.1 solve the issue? It work fine normally, but it occurs once in a while, probably after dyno restart.

Owner

justinfrench commented May 22, 2015

@scarver2 @xlymian Haml and Rails < 4.1.10 seems to be common between you so far.
@vfilesgroup are/were you using Haml and Rails < 4.1.10 too?

@xlymian I don't know if upgrading to 4.1.10 will resolve the issue (because I don't understand what the issue is), but @scarver2's post hints that this might help. If you do try some upgrades, it'd be awesome if you do one thing at a time as much as possible, and report back at each step so we can try to isolate it.

naoa commented Sep 15, 2015

Hi,
This problem occured with our environment, too.
We are running on heroku with ruby 2.1.5, rails 4.1.13, haml 4.0.7, puma 2.13.4 and formtastic-2.3.1(also tried 3.1.3 but it occured as same).
We have realized this issue may be caused by multithread access.
This issue is able to reproduced 100% by our development environment with the following case.

  • sets config.eager_load and config.cache_classes= true
  • execute rails server using puma
  • multi threading access with the number of concurrent access is over 10 as following.

e.g. if using apache2 ab

 ab -k -c 10 -n 10 http://localhost:3000/en/articles

Is the following code threadsafe?
Can the formtastic execute with multi thread environment?

https://github.com/justinfrench/formtastic/blob/3.1.3/lib/formtastic/helpers/input_helper.rb#L337-L348

mponto commented Sep 15, 2015

It seems the reason why this happens is because Formtastic::Inputs is eager_loaded.
While loading Formtastic::Inputs and its children caused by the first access, if other requests refer Formtastic::Inputs then the object is defined but not loaded, so can't find consts like TextInput, HiddenInput. After fully loaded, then the consts are defined so exceptions won't happen again.
(Sorry if my comments are something wrong as I'm not so good at concurrent programming)

I don't think it's good way to resolve, but this example removes the errors because the constants are loaded when initialization

in config/initializers/formtastic.rb

# define constants in advance
Formtastic::Inputs::StringInput
Formtastic::Inputs::TextInput
Formtastic::Inputs::CountryInput
Formtastic::Inputs::HiddenInput
etc

mponto commented Sep 16, 2015

Sorry I misunderstood about eager loading.
Maybe what happens here is that Formtastic::Inputs are not loaded eagerly but jumped to the objects premised to be already loaded.

Collaborator

mikz commented Mar 26, 2016

I think we could/should add eager_autoload to load all inputs when formtastic is loaded in production environment. That should fix it in production.

Will try to prepare a patch for 4.0 beta release.

Basically, doing http://blog.plataformatec.com.br/2012/08/eager-loading-for-greater-good/

mikz added a commit to mikz/formtastic that referenced this issue Mar 26, 2016

mikz added a commit to mikz/formtastic that referenced this issue Mar 26, 2016

@justinfrench justinfrench added this to the 4.0 beta milestone Mar 26, 2016

@justinfrench justinfrench added the bug label Mar 26, 2016

Collaborator

mikz commented Mar 27, 2016

So I just merged a possible fix (#1196) to the 4.0-dev branch. Would be awesome, if someone could try it. There is not so many changes between latest release 3.1.4 (released yesterday) and that branch. Just drops Rails 3 and 4.0 support plus removes some deprecations.

@mikz mikz closed this in 8f055ab Mar 27, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment