Здравствуйте, при попытке подключения к административному интерфейсу у меня появляется пустой экран. Я не могу выполнять обновления, например, хотя являюсь администратором.
Что мне делать?
Спасибо за помощь.
Мюриль
Вы можете попробовать безопасный режим. Также рекомендуется выполнить обновление через командную строку.
Обновление: Я выполнил корректную последовательность bootstrap, destroy и start с настройкой из 2 контейнеров, и теперь отображаемые номера версий обновлены, а интерфейс администратора снова работает.
Остальная часть поста оставлена для истории.
У меня возникла проблема, возможно, схожая с описанной. Интерфейс администратора загружается, но отображает только вкладки вверху, а основная область контента пуста:
Логи консоли браузера
При просмотре логов консоли браузера я вижу ошибки, такие как:
[Error] Error: VM BUG: Target must be set before attempting to jump
vendor.xxxxx-xxxx.js
Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
Стек ошибок
[Error] Error: VM BUG: Target must be set before attempting to jump
b (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:131956)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:69428)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:156653)
_runExpiredTimers (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:160801)
[Error] Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1310)
h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1311)
(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:3065)
h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1375)
requireModule (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:599)
_extractDefaultExport (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:269780)
resolveOther (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266326)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266888)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262092)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262185)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262275)
c (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:260192)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:258815)
getRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:56849)
fetchRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:267571)
_getQPMeta (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63399)
_hydrateUnsuppliedQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:64113)
_prepareQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63271)
normalizeQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38898)
_generateURL (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38990)
eA (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:202925)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49065)
X (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:140358)
T (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49044)
eM (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:80191)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:79868)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:70930)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:65312)
evaluateSyscall (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111047)
evaluateInner (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110609)
evaluateOuter (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110528)
next (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121496)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121359)
handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:112232)
handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:114799)
throw (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111583)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:68993)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:155980)
Процесс обновления (2 контейнера)
Проблема впервые возникла при попытке завершить обновление через интерфейс администратора Discourse, где мне было показано, что сначала необходимо обновить Docker Manager.
После обновления Docker Manager проблема проявилась, поэтому я подключился к серверу по SSH и выполнил ручное обновление (для 2 контейнеров) только для web_only:
cd /var/discourse
git pull
./launcher bootstrap web_only
./launcher stop web_only && ./launcher start web_only
^^^^
⚠️ Это неправильно! Используйте destroy, как указано ниже. ⚠️
Любопытно, что путь /about.json всё ещё показывает, что запущена версия 3.4.0.beta4-dev, что, как я думал, было исходной версией, так как исходное письмо касалось обновления с 3.4.0.beta4-dev до 3.5.0.beta1.
Я перепроверил git log, и, похоже, по крайней мере репозиторий discourse_docker находится на последнем коммите 3715498fc188d60c0b579443383c4e973cf26f59 на момент написания этого сообщения.
Режим безопасного запуска работает
Я не знал о режиме безопасного запуска, но, apparently, проблема не возникает, если я отключаю ВСЕ клиентские плагины.
Отключение только неофициальных клиентских плагинов и кастомизаций не решает проблему, так как я перепробовал все комбинации, чтобы сузить круг причин.
| Опция | Результат |
|---|---|
no_unofficial_plugins |
 |
no_plugins |
 |
no_themes |
|
Отключение docker_manager не помогает
Я попробовал закомментировать плагин docker_manager в секции hooks/after_code, затем пересобрал контейнер web_only и выполнил stop && start, но вышеупомянутое сообщение об ошибке на стороне клиента всё ещё сохраняется.
Это также приводит к появлению ещё одной ошибки: при посещении страницы администратора выводится this.class.create is not a function, но, возможно, это ожидаемое поведение при отключении базового плагина docker_manager для данного теста:
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
at loader.js:247:1
at h (loader.js:258:1)
at u.findDeps (loader.js:168:1)
at h (loader.js:262:1)
at requireModule (loader.js:24:1)
at f.get (composer.js:874:1)
at push.98673._extractDefaultExport (composer.js:874:1)
at push.98673.resolveOther (composer.js:874:1)
at push.98673.resolve (composer.js:874:1)
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
index.js:78 Uncaught TypeError: this.class.create is not a function
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
Опять же, использование режима безопасного запуска с опцией no_plugins позволяет временно обойти проблему.
Я действовал по памяти, используя команды для минимального времени простоя при обновлении с двумя контейнерами, и, похоже, моей памяти нельзя доверять! 
После использования правильной команды для удаления (destroy) и последующего запуска нового контейнера после выполнения bootstrap я вижу, что версии обновлены, а административный интерфейс работает как ожидалось.
Обновляли ли вы контейнер данных? Вам следует это сделать, но сначала ознакомьтесь с обновлением PostgreSQL 15. Или, если вы действительно не любите читать, просто выполните ./launcher rebuild data дважды, и всё должно быть в порядке. Затем вам нужно уничтожить контейнер данных и запустить веб-контейнер (иначе он будет искать старый контейнер данных, который вы уничтожили).
Пока нет, но спасибо, что беспокоитесь!
Я уже планировал настроить новый более мощный сервер, поэтому просто изучал возможность создания резервной копии из Discourse 3.5 + PG13 и последующего восстановления на Discourse 3.5 + PG15 на другом хосте.
Мне не нравится длительные простои, и в прошлом я временно переводил сообщество в режим только для чтения, выполнял резервное копирование и восстановление между экземплярами серверов, и это фактически происходило без простоя (кроме, конечно, периода только для чтения)… поэтому я подумал, что стоит изучить и протестировать, работает ли это при переходе между версиями PG.
В противном случае я просто решусь и сначала выполню обновление до PG15, а затем перейду на новый сервер. 
Работает. В любом случае, вероятно, пришло время обновить вашу ОС. Просто запустите новый сервер и восстановите резервную копию.
У меня точно такая же проблема. Спасибо за помощь. Мой веб-мастер Бенджамин прочитает ваше сообщение.
Мюриэль
Вот что случилось со мной. Единственным вариантом было развёртывание нового сервера и восстановление из резервной копии.
Он говорит по делу. Не тратьте время на отладку. Этот совет позволит вам быстро приступить к работе.
В итоге я выполнил резервное копирование и восстановление, и всё прошло как ожидалось.
Для справки, на случай, если кто-то ещё столкнётся с похожей проблемой…
Сначала я столкнулся с небольшой проблемой: процесс восстановления, по-видимому, вызывает внутреннюю команду uploads:migrate_to_s3, из-за чего он зависал.
2025-02-26 00:24:16] Миграция базы данных...
[2025-02-26 00:24:24]
[2025-02-26 00:24:24] Переподключение к базе данных...
[2025-02-26 00:24:24] Перезагрузка настроек сайта...
[2025-02-26 00:24:24] Отключение исходящей почты для пользователей, не являющихся сотрудниками...
[2025-02-26 00:24:24] Отключение режима только для чтения...
[2025-02-26 00:24:24] Очистка кэша категорий...
[2025-02-26 00:24:24] Перезагрузка переводов...
[2025-02-26 00:24:24] Переназначение загрузок...
[2025-02-26 00:24:24] Восстановление загрузок, это может занять некоторое время...
[2025-02-26 00:25:09] ИСКЛЮЧЕНИЕ: 12 из 12208 загрузок не были перенесены в S3. Миграция в S3 не удалась для БД 'default'.
[2025-02-26 00:25:09] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:73:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:383:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:354:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2025-02-26 00:25:09] Попытка отката...
[2025-02-26 00:25:09] Выполнение отката...
[2025-02-26 00:25:10] Очистка...
В итоге я выполнил несколько SQL-запросов в контейнере с данными, чтобы понять, что происходит.
./launcher enter data
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%s3%';
Это вернуло несколько стандартных встроенных элементов Discourse, поэтому я попробовал обратный запрос:
SELECT url from uploads where url LIKE '%s3%' limit 10;
Это дало множество совпадений в формате:
//{my-bucket-name}.s3.dualstack.us-east-2.amazonaws.com/original/2X/5/{image-id}.jpeg
Затем я попробовал запрос, чтобы получить все элементы, кроме тех, которые соответствуют хосту s3.dualstack, и обнаружил, что есть 12 старых записей, использующих немного другой формат (совпадающий с количеством неудачных загрузок из предыдущего лога восстановления).
//{my-bucket-name}.s3-us-east-2.amazonaws.com/{file-path}.jpeg
Когда я проверил существование этих файлов в самом бакете, их не оказалось, поэтому я удалил их с помощью команды вроде:
DELETE FROM uploads where url LIKE '%{my-bucket-name}.s3-us-east-2.amazonaws.com%';
После этого резервное копирование и восстановление прошли успешно!
PS. Не забудьте снова включить отправку писем после восстановления резервной копии!
/admin/site_settings/category/all_results?filter=disable_email