mainio/decidim-module-term_customizer

Stack level too deep error

Closed this issue · 5 comments

carlobeltrame commented

When installing this gem in an existing Decidim project, I get a "stack sevel too deep" exception. Repeating part of the stack trace:

[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/bundler/gems/decidim-module-term_customizer-b9248e2abd52/lib/decidim/term_customizer/loader.rb:35:in `translations_hash'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/bundler/gems/decidim-module-term_customizer-b9248e2abd52/lib/decidim/term_customizer/i18n_backend.rb:37:in `translations'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/bundler/gems/decidim-module-term_customizer-b9248e2abd52/lib/decidim/term_customizer/i18n_backend.rb:50:in `lookup'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/base.rb:32:in `translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/chain.rb:63:in `block (2 levels) in translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/chain.rb:61:in `catch'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/chain.rb:61:in `block in translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/chain.rb:60:in `each'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/chain.rb:60:in `translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/fallbacks.rb:48:in `block (2 levels) in translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/fallbacks.rb:47:in `catch'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/fallbacks.rb:47:in `block in translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/fallbacks.rb:45:in `each'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n/backend/fallbacks.rb:45:in `translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n.rb:206:in `block in translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n.rb:202:in `catch'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/i18n-1.8.2/lib/i18n.rb:202:in `translate'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/activesupport-5.2.4.3/lib/active_support/core_ext/array/conversions.rb:70:in `to_sentence'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/activesupport-5.2.4.3/lib/active_support/duration.rb:379:in `inspect'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/dalli-2.7.10/lib/active_support/cache/dalli_store.rb:404:in `inspect'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/dalli-2.7.10/lib/active_support/cache/dalli_store.rb:404:in `log'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/dalli-2.7.10/lib/active_support/cache/dalli_store.rb:385:in `instrument_with_log'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/gems/dalli-2.7.10/lib/active_support/cache/dalli_store.rb:106:in `fetch'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/bundler/gems/decidim-module-term_customizer-b9248e2abd52/lib/decidim/term_customizer/loader.rb:35:in `translations_hash'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/bundler/gems/decidim-module-term_customizer-b9248e2abd52/lib/decidim/term_customizer/i18n_backend.rb:37:in `translations'
[ec9c99d9-207c-435f-bb7a-3f51cf49ebd5] bundle/ruby/2.5.0/bundler/gems/decidim-module-term_customizer-b9248e2abd52/lib/decidim/term_customizer/i18n_backend.rb:50:in `lookup'
...

We are using Decidim v0.21, and decidim-module-term_customizer from the 0.21-stable branch.
Do you have any idea what could be causing this error? Thanks!

carlobeltrame commented

The issue was caused by setting log_level = :debug. I was able to fix it using the following config to set the log level for just the cache store:

  # config/environments/production.rb
  # Silence the cache store, the decidim-term_customizer module doesn't work otherwise
  config.after_initialize do
    Rails.cache.logger.level = Logger::INFO
  end

Nevertheless, this might be something you'd want to think about, or document clearly.

  • ❤️2
mrcasals commented

@carlobeltrame thank you so much for this, it works like a charm (although I sincerely don't understand how 😕)

carlobeltrame commented

Well, as far as I understand, term customizer hooks into the I18n.t (AKA translate) function to replace the customized translations on the fly. But term customizer also has caching functionality, so it asks the cache store first whether there is an already cached customized string before it goes to the database to fetch it. At that point, if the cache store is set to log in debug mode, it wants to log this lookup. Apparently, for logging that message (using inspect and to_sentence), it internally uses I18n.t (or rather translate), and so the endless cycle begins.

mrcasals commented

Oooooh that makes sense, thanks for the explanation! 😄

ahukkanen commented

Fixed by 27d2222.

I found out #mute in ActiveSupport::Cache::Store which should take care of this issue:
https://api.rubyonrails.org/classes/ActiveSupport/Cache/Store.html#method-i-mute

If the issue still persists after this, feel free to reopen or send a PR.

This is part of the 0.22.0 release.

Included also in v0.23.0 which is also pushed to RubyGems.

  • 🎉1