Sidekiq не запускается после включения Zeitwerk в Docker dev

averi · 02.Октябрь.2019 10:44:03

Недавно мы обновились с версии 2.4.0.beta4 до 2.4.0.beta5, и Sidekiq не запускается, выдавая следующий стек ошибок:

> $ bundle exec sidekiq -C config/sidekiq.yml
> uninitialized constant SiteSetting::SiteSettingExtension
> /discourse/app/models/site_setting.rb:5:in `<class:SiteSetting>'
> /discourse/app/models/site_setting.rb:3:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:23:in `require'
> /discourse/vendor/bundle/ruby/2.5.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:23:in `require'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/dependencies/interlock.rb:14:in `block in loading'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/concurrency/share_lock.rb:151:in `exclusive'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/dependencies/interlock.rb:13:in `loading'
> /discourse/config/initializers/004-message_bus.rb:120:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:667:in `block in load_config_initializer'
> /discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-6.0.0/lib/active_support/notifications.rb:182:in `instrument'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:666:in `load_config_initializer'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:624:in `block (2 levels) in <class:Engine>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:623:in `each'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/engine.rb:623:in `block in <class:Engine>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `instance_exec'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `run'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:61:in `block in run_initializers'
> /usr/local/lib/ruby/2.5.0/tsort.rb:228:in `block in tsort_each'
> /usr/local/lib/ruby/2.5.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
> /usr/local/lib/ruby/2.5.0/tsort.rb:422:in `block (2 levels) in each_strongly_connected_component_from'
> /usr/local/lib/ruby/2.5.0/tsort.rb:431:in `each_strongly_connected_component_from'
> /usr/local/lib/ruby/2.5.0/tsort.rb:421:in `block in each_strongly_connected_component_from'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:50:in `each'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:50:in `tsort_each_child'
> /usr/local/lib/ruby/2.5.0/tsort.rb:415:in `call'
> /usr/local/lib/ruby/2.5.0/tsort.rb:415:in `each_strongly_connected_component_from'
> /usr/local/lib/ruby/2.5.0/tsort.rb:349:in `block in each_strongly_connected_component'
> /usr/local/lib/ruby/2.5.0/tsort.rb:347:in `each'
> /usr/local/lib/ruby/2.5.0/tsort.rb:347:in `call'
> /usr/local/lib/ruby/2.5.0/tsort.rb:347:in `each_strongly_connected_component'
> /usr/local/lib/ruby/2.5.0/tsort.rb:226:in `tsort_each'
> /usr/local/lib/ruby/2.5.0/tsort.rb:205:in `tsort_each'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/initializable.rb:60:in `run_initializers'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/application.rb:363:in `initialize!'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/railtie.rb:190:in `public_send'
> /discourse/vendor/bundle/ruby/2.5.0/gems/railties-6.0.0/lib/rails/railtie.rb:190:in `method_missing'
> /discourse/config/environment.rb:7:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.7/lib/sidekiq/cli.rb:288:in `boot_system'
> /discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.7/lib/sidekiq/cli.rb:46:in `run'
> /discourse/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.7/bin/sidekiq:12:in `<top (required)>'
> /discourse/vendor/bundle/ruby/2.5.0/bin/sidekiq:23:in `load'
> /discourse/vendor/bundle/ruby/2.5.0/bin/sidekiq:23:in `<top (required)>'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `load'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `kernel_load'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:28:in `run'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:463:in `exec'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:27:in `dispatch'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:18:in `start'
> /usr/local/bin/bundle:30:in `block in <main>'
> /usr/local/lib/ruby/site_ruby/2.5.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
> /usr/local/bin/bundle:22:in `<main>'

Не могли бы вы подсказать, куда стоит посмотреть дальше? Спасибо!

Falco · 02.Октябрь.2019 12:14:51

Это не установка, выполненная по нашему официальному руководству, поэтому мы мало чем можем вам помочь.

averi · 02.Октябрь.2019 12:27:00

Сейчас мы используем Discourse на OpenShift, так что это точно не стандартная установка. Я изучу официальное руководство и проверю, не упустил ли я что-то в текущем развёртывании. Спасибо.

azawawi · 02.Октябрь.2019 12:39:12

На самом деле даже следующая команда Docker вызывает тот же самый стек трассировки в моей машине Vagrant с Discourse через VirtualBox:

vagrant ssh -c '(cd ~/discourse && sudo bin/docker/sidekiq)'

Falco · 02.Октябрь.2019 12:42:31

Ты уверен в этом? В официальном руководстве ничего не сказано о ручном запуске Sidekiq, и там нет папки /home/discourse.

Ты разве запускаешь установку для разработки в продакшене ??

azawawi · 02.Октябрь.2019 12:45:13

Я использую команды Docker для тестирования и разработки плагинов Discourse.

Другой скрипт, который я сейчас использую:

# Очистить временный кэш Discourse и запустить Rails в режиме разработки
vagrant ssh -c '(rm -rf ~/discourse/tmp/cache)'
vagrant ssh -c '(cd ~/discourse && sudo bin/docker/rails s)'

azawawi · 02.Октябрь.2019 12:47:02

Конечно нет

azawawi · 02.Октябрь.2019 12:50:17

@Falco, я думаю, это связано с

Что ты думаешь?

Falco · 02.Октябрь.2019 12:51:30

Возможно, так и есть. То, что вы не уточнили, что это ваша среда разработки, а не dev-окружение, не помогло.

Итак, вы утверждаете, что наша docker-среда разработки в данный момент сломана?

azawawi · 02.Октябрь.2019 12:52:57

Да, похоже на это.

azawawi · 02.Октябрь.2019 12:59:56

Откат этого коммита снова заставляет sidekiq работать.

Falco · 02.Октябрь.2019 13:11:17

Похоже, это для тебя, @kris.kotlarek

kris.kotlarek · 02.Октябрь.2019 23:32:35

Хорошо, я понимаю, что произошло — это моя ошибка. Я удалил множество require_dependency, так как при использовании автозагрузчика Zeitwerk они больше не требуются.

Однако в application.rb у нас есть следующее:

if !Sidekiq.server?
  config.autoload_paths += Dir["#{config.root}/lib"]
end

Это означает, что Sidekiq не ищет директорию lib для поиска зависимостей, и мы явно указываем, что требуется в конкретных файлах.

Я могу вернуть require_dependency для файлов, используемых Sidekiq, или убрать эту проверку в application.rb.

Думаю, мы использовали явный require, чтобы сэкономить память для воркеров, поэтому, вероятно, стоит придерживаться этого подхода. Я верну require_dependency.

@sam, как ты думаешь?

sam · 02.Октябрь.2019 23:36:45

Нужно убрать проверку. Мне она не нравится, потому что непонятно, станет ли ваш процесс Sidekiq или нет. В наших развёртываниях у нас так: unicorn master → fork → sidekiq worker. На момент fork файл application.rb уже был проанализирован.

azawawi · 03.Октябрь.2019 07:18:46

@kris.kotlarek Спасибо за исправление. Sidekiq теперь работает вместе с официальными плагинами Discourse .

Однако большинство моих плагинов от сторонних разработчиков с задачами не работают сейчас . Скорее всего, это вызвано тем, что следующее изменение не было применено к их классам Jobs::.

Сломанные плагины от сторонних разработчиков

github.com/gdpelican/babble

app/jobs/regular/babble_post_alert.rb

master


      
          module Jobs
            class BabblePostAlert < ::Jobs::Base
              def execute(args)
                return unless post = Post.find_by(id: args[:post_id])
                return unless post.topic&.archetype == Archetype.chat
                Babble::PostAlerter.new.after_save_post(post)
              end
            end
          end

github.com/procourse/procourse-static-pages

app/jobs/onceoff/migrate_static_pages_plugin.rb

master


      
          module Jobs
            class MigrateStaticPagesPlugin < ::Jobs::Onceoff
              # Migrate content from dl_static_pages name to procourse_static_pages
              def execute_onceoff(args)
                  dl_page_presence = PluginStoreRow.where(plugin_name: "dl_static_pages").exists?
                  if dl_page_presence
                      # Migrate the page content rows
                      PluginStoreRow.where(plugin_name: 'dl_static_pages')
                      .find_each do |row|
                          PluginStore.set("procourse_static_pages", row.key, row.value)
                          row.destroy # clean up dl_static_pages row
                      end

github.com/discourse/discourse-whos-online

plugin.rb

main


      
          # frozen_string_literal: true
          
          # name: discourse-whos-online
          # about: Display a list of online users at the top of the screen
          # meta_topic_id: 52345
          # version: 2.0
          # authors: David Taylor
          # url: https://github.com/discourse/discourse-whos-online
          
          enabled_site_setting :whos_online_enabled
          
          register_asset "stylesheets/whos_online.scss"
          
          after_initialize do
            module ::DiscourseWhosOnline
              CHANNEL_NAME = "/whos-online/online"
            end
          
            register_presence_channel_prefix("whos-online") do |channel_name|
              if channel_name == "/whos-online/online"
                config = PresenceChannel::Config.new(timeout: SiteSetting.whos_online_active_timeago * 60)
                if SiteSetting.whos_online_display_public
                  config.public = true
                else
                  config.allowed_group_ids = [::Group::AUTO_GROUPS[:trust_level_0]]
                end
                config.count_only = SiteSetting.whos_online_count_only
                config
              end
            end
          
            on(:user_seen) do |user|
              hidden = false
              hidden ||= user.user_option.hide_presence if defined?(user.user_option.hide_presence)
              hidden ||= user.id < 0
              next if hidden
              PresenceChannel.new(DiscourseWhosOnline::CHANNEL_NAME).present(
                user_id: user.id,
                client_id: "seen",
              )
            rescue PresenceChannel::InvalidAccess
            end
          
            add_to_serializer(
              :site,
              :whos_online_state,
              include_condition: -> do
                @whos_online_channel ||= PresenceChannel.new(DiscourseWhosOnline::CHANNEL_NAME)
                @whos_online_channel.can_view?(user_id: scope.user&.id)
              end,
            ) do
              @whos_online_channel ||= PresenceChannel.new(DiscourseWhosOnline::CHANNEL_NAME)
              PresenceChannelStateSerializer.new(@whos_online_channel.state, root: nil)
            end
          end

kris.kotlarek · 03.Октябрь.2019 23:07:13

Вы правы, теперь все Jobs::Onceoff, Jobs::Base и Jobs::Scheduled требуют использования ::

Я исправил discourse-whos-online и создал pull-запросы для других плагинов:

azawawi · 04.Октябрь.2019 05:13:30

@kris.kotlarek Большое спасибо . Я ознакомился с вашим постом об автозагрузчике Zeitwerk. Планируется ли внедрение функции автоматической перезагрузки плагинов в режиме разработки для ускорения работы над плагинами?

kris.kotlarek · 04.Октябрь.2019 05:33:36

Ещё остались места, содержащие require или require_dependency, но многие из них уже удалены.

Я думаю, что теперь код плагина должен автоматически перезагружаться без проблем. Нужно немного поэкспериментировать, чтобы убедиться, но у меня позитивные ощущения

azawawi · 06.Октябрь.2019 09:21:19

Похоже, нам сначала нужно включить это, согласно его документации. Я попробовал в режиме разработки, но изменения плагинов не были перезагружены

fzngagan · 06.Октябрь.2019 09:23:06

Это было бы здорово. У меня была надежда, но ваши слова дают мне еще больше надежды. Разработчики плагинов будут в восторге от этого.

Тема		Ответов	Просм.
Upgrading Discourse to Zeitwerk Development dev-news	14	3390	02.10.2019
Sidekiq not working Self-hosting	10	1183	02.10.2023
"Ensure sidekiq is running." when it is definitely running Self-hosting	19	7866	24.10.2015
Development environment : running sidekiq and discourse at startup Development	14	5594	30.10.2018
Sidekiq not running. Sidekiq heartbeat test failed, restarting Self-hosting unsupported-install	15	2897	10.06.2020

Сломанные плагины от сторонних разработчиков

Связанные темы