> ## Documentation Index
> Fetch the complete documentation index at: https://nexohub.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Что 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` на прокси, хотя трудно представить,
зачем.

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

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

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

* **Она не проверяет, устраивает ли 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).
```

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

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

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

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

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

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

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

```
/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, поэтому запускайте стейдж до
правок. Всё, что изменено до этого, уже находится на каждом бэкенде.

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

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

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

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

```yaml theme={null}
notify:
  webhook_url: "https://discord.com/api/webhooks/..."
  events:
    - validation_failed
    - reload_failed
    - collision
    - version_drift
    - rollback
```

Если убрать `push` из этого списка, останется только то, что требует внимания. Полный
список — в [конфигурации прокси](/ru/reference/proxy-config#notifications).

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.