Как не сломать свою сеть

Что NexoHub проверяет перед отправкой и как отменить правку, которая всё же прошла.

Одно место для исправления ошибки — это и одно место, где её можно совершить, а изменение доходит до каждого бэкенда за секунды после сохранения файла. Ничто не просит у вас подтверждения.

Поэтому между вашим редактором и вашими игроками стоят две вещи: ничего не отправляется, пока не пройдёт разбор, и каждый отправленный набор файлов сохраняется.

​

Ничего не отправляется, пока не пройдёт разбор

Перед любой отправкой NexoHub читает каждый файл .yml, .yaml, .json и .mcmeta в nexo-data/ и разбирает его. Если хоть один из них не проходит разбор, не отправляется вообще ничего, и ваши бэкенды остаются на последних файлах, которые разбор прошли.

[NexoHub] Nothing was pushed: 1 file(s) do not parse.
  _shared/items/swords.yml line 14: could not find expected ':', while scanning a simple key
[NexoHub] The backends are still on the last files that parsed. Fix these and push again.

Придерживаются все ваши файлы, а не только сломанный.

Отключить это можно параметром sync.validate: false на прокси, хотя трудно представить, зачем.

Для проблем в YAML указываются файл и строка. Для проблем в JSON — только файл. Перечисляется не более 15, потому что пятьдесят сломанных файлов обычно сломаны одним и тем же способом, и причиной, как правило, является первый.

​

Что эта проверка не ловит

Она проверяет, что ваши файлы читаемы, а не что они корректны.

• Она не проверяет, устраивает ли Nexo содержимое файла. Аккуратный YAML-файл, указывающий несуществующий тип предмета, проходит эту проверку и всё равно падает на бэкенде.
• Проверка JSON — это минимальная планка. Она ловит пропущенную скобку или запятую. Она примет кое-что из того, что клиент Minecraft не принял бы.
• Файлы больше 32 МБ пропускаются, как и скрытые файлы и резервные копии с ~.

Она нужна, чтобы остановить ту одну опечатку, которая кладёт все бэкенды одновременно. После этого всё равно смотрите на /nexohub status.

​

Проверка без отправки

/nexohub validate

Та же проверка, без отправки. Запускайте её после adopt или когда вы на середине правки и хотите узнать результат до сохранения последнего файла.

Прокси также выполняет её при запуске и печатает всё найденное, поэтому файл, сломанный со времени последнего перезапуска, не останется незамеченным.

​

Каждый отправленный набор файлов сохраняется

Снимок nexo-data/ делается всякий раз, когда ваши файлы меняются и проходят проверку. Ничего не хранится дважды, поэтому перезапуск, /nexohub push и тронутый, но не изменённый файл ничего не стоят.

Снимки также делаются перед двумя операциями, которые перезаписывают ваши файлы целиком: /nexohub adopt и самим /nexohub rollback.

[NexoHub] 4 snapshot(s), newest first:
  1769517840000-5d935602  118 file(s)  3m ago  your edit
  1769516010000-0c47b7c6  117 file(s)  33m ago  your edit
  1769509220000-b41f0d7e  117 file(s)  2h ago  a manual push
  1769508900000-77c1a2e5  96 file(s)  2h ago  before adopting lobby
[NexoHub] /nexohub rollback <id> puts one back. The current files are snapshotted first.

Причина в конце строки — то, из-за чего снимок был сделан. sync.snapshots определяет, сколько снимков хранить, по умолчанию 20; 0 отключает историю.

​

Откат

/nexohub rollback 1769516010000-0c47b7c6

Достаточно первых нескольких символов идентификатора. О неоднозначном префиксе будет сообщено, а не угадано.

[NexoHub] Restored 117 file(s) from 1769516010000-0c47b7c6, taken 36m ago.
[NexoHub] 2 file(s) added since then were removed.
[NexoHub] Pushed to 3 of 3 backend(s).

Вторую строку стоит перечитать дважды.

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

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

[NexoHub] The restored files do not parse, so nothing was pushed. That snapshot predates validation.

Снимок содержит те же файлы, что и отправка, поэтому скрытых файлов, резервных копий с ~ и всего, что больше 64 МБ, в нём нет, и они не вернутся. Если вы храните крупные исходники графики в nexo-data/, делайте их резервную копию и в другом месте.

​

Сначала попробовать на одном сервере

Откат — это ответ, когда игроки уже увидели изменение. Стейджинг — ответ до того, как они его увидят.

/nexohub stage dev

Все бэкенды, кроме dev, удерживаются на файлах в их нынешнем виде. Редактируйте nexo-data/, смотрите на dev и завершите одним из двух способов:

/nexohub promote     the network gets what dev has been running
/nexohub discard     nexo-data/ goes back as the stage found it

Указание сервера в /nexohub push этого не делает и никогда не делало. Бэкенд, которому не отправили изменение, ждёт на long poll и подтягивает то же изменение секундой позже, поэтому единственный способ удержать правку от боевых серверов — чтобы хаб продолжал отдавать им то, что у них уже было. Именно это и делает стейдж.

Копия делается при выполнении stage, а не при promote, поэтому запускайте стейдж до правок. Всё, что изменено до этого, уже находится на каждом бэкенде.

Стейдж продолжает действовать, пока вы его не примените или не отмените, включая перезапуски. Это сделано намеренно, но это означает, что забытый стейдж — это сеть, которая тихо перестаёт получать ваши правки. /nexohub status и /nexohub doctor оба сообщают, когда стейдж активен, а лог прокси называет его при каждой удержанной отправке.

Отмена тоже не разрушительна. Перед возвратом nexo-data/ делается снимок, так что выброшенная работа всё ещё доступна в /nexohub history.

​

Как об этом узнать

Консоль — не то место, где большинство людей узнают, что что-то не так. Направьте notify на вебхук, и сбои будут приходить к вам сами:

notify:
  webhook_url: "https://discord.com/api/webhooks/..."
  events:
    - validation_failed
    - reload_failed
    - collision
    - version_drift
    - rollback

Если убрать push из этого списка, останется только то, что требует внимания. Полный список — в конфигурации прокси.

validation_failed — тот, который стоит иметь. Файл, не прошедший разбор, не отправляется, поэтому сеть продолжает работать и никто ничего не замечает, пока кто-то не спросит, почему его новый предмет так и не появился.