Настройки сами возвращаются к исходным значениям

У меня есть экземпляр Discourse, который работает уже неделю, и он проявляет некоторые из самых странных симптомов, которые я не могу решить. Отчасти это связано с тем, что в логах вообще нет никакой полезной информации.

Самый заметный симптом: если я захожу в настройки, изменяю параметр и нажимаю зеленую галочку, система принимает изменения, и всё выглядит нормально. Однако если я затем обновлю страницу настроек, с большой вероятностью там может отобразиться либо старое значение, либо новое. Если продолжать обновлять страницу, то иногда показывается одно значение, иногда другое.

Хуже того, проблема возникает не только на экране настроек: иногда меняется и функциональность самого сервера. Например, при попытке загрузить новый логотип он может то отображаться как старый, то как новый.

Чтобы ответить на очевидный вопрос: нет, я не запускаю несколько экземпляров за балансировщиком нагрузки — у меня только один экземпляр.

Не уверен, связано ли это, но также заметил, что плагин Discourse Math отображается неправильно. Формулы корректно показываются в предпросмотре, но после публикации, похоже, не подключается JavaScript, из-за чего они не рендерятся должным образом. Проблема с математикой не является приоритетной, но упомяну её на всякий случай — возможно, это даст дополнительные подсказки.

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

Это указывает на серьезную неисправность установки. Удалите все сторонние плагины и выполните повторную сборку.

Я пробовал это, но безрезультатно. Скорее всего, проблема в том, как я его устанавливаю.

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

Как вы устанавливаете? Вы используете официальное руководство, предоставленное на GitHub?

Изначально я использовал именно этот процесс. К сожалению, он не поддерживает большинство корпоративных производственных сред, доступных мне. Большинство фреймворков управляют запуском и развёртыванием контейнеров. Из-за специфики стандартного подхода к установке работать в этих инструментах и средах невозможно.

Поэтому я пытаюсь доработать/исправить процесс, чтобы он мог устанавливаться в любой среде, поддерживающей стандартное развёртывание на основе Docker. Хотя эта работа в основном идёт успешно, я столкнулся с ошибкой, о которой сообщал изначально.

Как только я всё настрою, конечно же, выпущу решение для других. Я ждал целый год, пока Discourse поддержит стандартный Docker, но решил внести свой вклад самостоятельно. Почти получилось, но, надеюсь, кто-то с большим опытом, чем у меня, подскажет, куда смотреть.

Пожалуйста, помогите! Даже просто подсказка, где искать или отлаживать это, или какие-либо идеи будут очень признательны.

Вы уверены, что запрос проходит корректно? Что вы видите во вкладке Network в инструментах разработчика?

Описанное вами поведение типично для среды, где возникают ошибки на стороне JavaScript.

Спасибо, это может оказаться очень полезным. Поскольку плагин MathJax то работал, то переставал работать, похоже, проблема связана с JavaScript.

Я зашел, очистил кэш и попытался изменить настройку, внимательно наблюдая за вкладкой Network. Ошибок не появилось ни до, ни после изменения настройки (хотя ошибка всё же проявилась).

Одна причина, по которой маловероятно, что изменение вообще не применяется, — это поведение системы. Я вношу изменение, затем обновляю страницу, и изменение, кажется, откатывается. Но если я просто продолжаю обновлять страницу (не пытаясь внести изменение повторно), то изменение появляется примерно в половине случаев. При каждом обновлении страницы есть около 50% шанса увидеть старую настройку или новую.

Также я обнаружил следующую ошибку в консоли, но, думаю, она не связана с проблемой?

Не удалось найти действие виджета actions-summary-item в реестре

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

У вас запущено несколько веб-контейнеров?

Я пробовал это, как и раньше. Это не помогло. Но я сомневаюсь, что действительно был в безопасном режиме. Я зашел в */safe-mode, появилось диалоговое окно для входа в безопасный режим, и я согласился. Однако я заметил, что используемая мной тема Material Design всё ещё отображалась. Так что, хотя я думал, что нахожусь в безопасном режиме, возможно, на самом деле это было не так?

В любом случае ошибка сохранялась.

Я не думаю, что он это делает… :wink:

Два контейнера: один для Sidekiq, другой для основного Discourse. Только один экземпляр пары. Я использую PostgreSQL и Redis как хостинговые сервисы на отдельных машинах.

Ой. Извините, это был очевидный вопрос, на который вы уже ответили.

Редактировать: возможно, это тоже не оно, но у меня была похожая проблема, когда я использовал базу данных Redis, которая уже использовалась другим процессом.

Кажется, я понял, почему безопасный режим не работал. Он отключался при обновлении страницы.

Только что протестировал в безопасном режиме — проблема всё ещё сохраняется.

И API-запрос возвращает 200?

Зависит от того, что вы имеете в виду. Во вкладке «Network» в инструментах разработчика для отладки всё отображается со статусом 200, в консоли есть только ошибка, о которой я упоминал выше (скорее всего, она не связана с этим). В логах Docker, когда я вношу изменение в настройку, вижу следующее, что подтверждает успешное выполнение: при обновлении страницы настроек в 50% случаев отображается старая настройка (ld), а в 50% — новая.

> 2019-08-20T13:14:15.960335498Z Started PUT "/admin/site_settings/categories_topics" for 213.127.19.53 at 2019-08-20 13:14:15 +0000
> 2019-08-20T13:14:15.968667966Z Processing by Admin::SiteSettingsController#update as */*
> 2019-08-20T13:14:15.968951769Z   Parameters: {"categories_topics"=>"25", "id"=>"categories_topics"}
> 2019-08-20T13:14:15.978407541Z   Rendering text template
> 2019-08-20T13:14:15.978607623Z   Rendered text template (0.0ms)
> 2019-08-20T13:14:15.978834745Z Completed 200 OK in 10ms (Views: 0.6ms | ActiveRecord: 0.0ms)
> 2019-08-20T13:18:39.821498901Z [ N 2019-08-20 13:18:39.8209 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6157, application /opt/bitnami/discourse (production)
> 2019-08-20T13:18:59.866033984Z [ N 2019-08-20 13:18:59.8655 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 5973, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:04.848923491Z [ N 2019-08-20 13:19:04.8484 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6018, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:08.900933057Z [ N 2019-08-20 13:19:08.9004 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 5995, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:09.499349110Z [ N 2019-08-20 13:19:09.4989 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6041, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:29.645095032Z Creating scope :open. Overwriting existing method Poll.open.

Так как же он был установлен? Если вы не используете стандартную установку, какой метод установки и пакет вы используете?

Ой… Bitnami…

О каких именно процессах идёт речь?

Это не использует стандартную установку, хотя я и использовал её как руководство для обучения. По сути, мне пришлось написать/изменить файлы Docker, чтобы они работали с docker-compose. Затем, когда docker-compose заработал локально, я преобразовал его в JSON-формат, чтобы можно было использовать инструменты aws-cli.

Таким образом, процесс установки значительно отличается от стандартного.