coa-server-manager/TODO.md

TODO

Подготовка 0.9.8, 2026-10-31

• Подготовлены исходники C:/games/source/per-race-manager, ветка fix/launcher-validation-candidate-20261031: изоляция bot configs на время проверки с точным восстановлением, повторное использование MySQL внутри validation, зависимость Dungeon Clear от SQUID, три режима логов и экспорт этапов launcher/control owner.
• Workspace: 840 тестов прошли, 60 ignored; последующие focused diagnostics: 11 прошли. Переводы новых заметок и UI подготовлены, web build/i18n/bridge/history checks прошли. Подробности и ограничения: C:/games/source/candidate-preparation-20261031.md.
• Не выпускать Manager до кандидата сервера. Installer ещё не собирался и не публиковался; подготовка источников не равна готовому кандидату.

Приоритет: проверка установки и обновления (2026-10-31)

• Локальные замеры массовых Companions (2026-10-31): отчёт C:/games/source/companions-benchmark-20261031/REPORT.md, сырые выборки/qualification в той же папке. Native worldserver SHA bd9f65ac7543fad8159231000d5ef6436a159aa009b65cbdc9541a0e9fe1ee7b, Ryzen 7 7700X/32 GiB, MapUpdate.Threads=1, все CPU доступны. Перед условиями восстанавливался один снимок персонажей. Без записи логов медианы среднего тика: 0 ботов 4.5 ms; 500 — 39 ms; 1000 — 91 ms; 2000 — 246 ms, поздний замер 259 ms. С обычными логами: 500 — 43.5 ms; 1000 — 111 ms. Запуск 2000 с логами дал 1381 ms, последующий полный Logger-off 363 ms, но нагрузка хоста менялась; чистый множитель логирования этими числами не доказан. Всего 9 условий с подтверждённым online; исходная база 21 шаблон/0 тестовых аккаунтов восстановлена, тестовые процессы остановлены. Повтор 2000 с логами подготовлен, но НЕ выполнен: на C: осталось около 300 MiB. Соответствующий PDB для функционального профиля отсутствует.

• Разобрать штатное завершение мира под большой популяцией:

  • В локальном бенчмарке ряд запусков (включая 2000 ботов и полностью отключённые логгеры) не завершились за 90 секунд после server shutdown 1s 0; пришлось завершать только тестовый процесс после сохранения измерений. Стек 2000-shutdown-stacks.txt показывает ожидание MSVCP140!Thrd_join, точный ожидаемый поток без matching PDB не установлен. Не объявлять это доказанной причиной пользовательского control.lock или влиянием только логов.

• Разобрать удержание control.lock после видимого запуска сервера:

  • Пользователь после hotfix v3 получил Another start/stop action is in progress при внешнем with launcher["control_lock"](), хотя мир отвечал и Manager показывал работающий сервер. Не считать это доказательством «зависшего файла»: Windows блокирует диапазон живым дескриптором.
  • На Python 3.14.7 точно воспроизведён конкурентный захват: второй лаунчер получает эту ошибку, после выхода владельца захват снова проходит. Причина долгого удержания у пользователя пока не установлена; нужны его свежие launch diagnostics.
  • Добавить безопасную диагностику владельца (PID, время создания, действие, этап ожидания) и проверить сериализацию Start/Stop/Restart/validation/recovery. Различать реальную занятость и прочие OSError захвата, которые сейчас маскируются одним сообщением. Не удалять lock и не завершать чужие процессы ради обхода.

• Проверка с ботами завершена (2026-10-31): пользователь показал работающие MySQL/auth/world, 2000 Companions онлайн и вход своим клиентом в мир после обновления. Это подтверждает обычный запуск с ботами после hotfix, но не пригодность массового автологина для validation. Ранний снимок показывает около 11 тиков/с на 2m32s работы; результат замера после прогрева пока неизвестен.

• Пользовательская проверка (2026-10-31): после hotfix лаунчера v3 и отключения автологина Companions обновление завершилось успешно (server 0.261030.90, Manager 0.9.7). Отдельная проверка с включёнными ботами пока не завершена.

• Сократить повторные запуски MySQL в установке/обновлении:

  • Пользователь после успешного обновления отметил большую длительность и многократные старты/остановки базы, в том числе на 85%. Проследить фактическую последовательность snapshot/SQL/schema/validation/recovery и повторно использовать уже запущенную, проверенную базу между совместимыми этапами.
  • Не убирать остановки, необходимые для согласованного backup/restore, замены файлов и восстановления после отказа. Сохранить гарантии rollback и владения процессами. Записать число стартов/остановок и длительность этапов до/после; проверить обновление без ботов и восстановление после ошибки.

• Временный конфиг проверки без массового запуска ботов:

  • Запрос владельца: грузить 2000 ботов ради проверки установки/обновления недопустимо. Облегчить все проверочные запуски, включая восстановление/повторную проверку, где применяется тот же путь запуска.
  • Факты случая: этап обновления 85%, CoA Companions поставили в очередь 2000 ботов; пользователь сообщает об остановке продвижения на 519 за 6 минут. Логи показывают 518 уникальных имён в ACTIVE_LIST. Это не SQUID. Место зависания и причинная связь с автологином пока не установлены.
  • Перед проверочным запуском временно отключать CoaBots.AutoLoginOnStartup и проверить другие пути автоматического входа/создания/заселения Companions, включая CoaBots.RandomSpawn.AutoLogin. Аналогично подавлять автоматическое заселение SQUID, если выбран этот модуль. Не подменять пользовательский выбор системы ботов и не отключать модуль целиком вместо проверки его инициализации.
  • Сохранять исходные байты/отсутствие изменяемых конфигов в журнале восстановления; вернуть их до обычного запуска как при успехе, так и при ошибке, отмене, rollback и восстановлении после прерывания Manager. Не оставлять автологин выключенным пользователю. Проверить primary и дополнительные realms.
  • Проверка должна подтверждать инициализацию ядра/выбранных модулей, SQL/schema, сервисы и отклик управляющего интерфейса; не ждать заполнения мира ботами и не создавать для этого тысячи персонажей. Вне validation обычный запуск сохраняет поведение пользовательских настроек.
  • Проверить сценарии с Companions и лимитом 2000, SQUID, выключенными ботами; успех, отказ запуска, прерывание и восстановление исходных конфигов. Добавить регрессионные проверки и changelog после реализации.

• Доставить исправление manage.py для PID 0 в согласованном серверном обновлении:

  • Серверная задача и готовый локальный hotfix описаны в C:/games/coa-server-build/TODO.md. Проверить импортируемый запуск через runpy/внешний вызов main() и штатный Manager update; диагностика должна работать при обоих способах загрузки.

UI / UX

• Предупреждение о несохранённых изменениях при переходе между вкладками (Unsaved Changes Guard / Modal):
  • Если у пользователя есть несохранённые изменения в настройках (ModulesPage, SettingsPage — сервер, боты и др.) и он переходит на другую вкладку (в боковом меню Shell.tsx или кнопками навигации), показывать pop-up диалог подтверждения.
  • Опции в диалоге:
    • Сохранить (Save) — сохранить внесённые изменения и перейти на выбранную страницу.
    • Сбросить (Discard) — отменить несохранённые изменения и перейти на выбранную страницу.
    • Отмена (Cancel) — остаться на текущей странице с сохранением введённых данных.
  • Контекст: Предотвратит случайную потерю настроек, когда пользователь меняет параметры модуля/сервера и сразу уходит на вкладку Overview для запуска сервера (см. Issue #45).

Сервер и стабильность

• Автоподнятие сервера при падении (Auto-restart on crash) со счётчиком и расшифровкой крашей:
  • Настройка: Чекбокс «Автоматически перезапускать сервер при падении» в настройках сервера / менеджера.
  • Поведение автоподнятия:
    • Перезапускать процесс сервера только если падение произошло внезапно (процесс завершился с ненулевым exit code, крашем или без команды от менеджера).
    • Если пользователь нажал кнопку «Стоп» (Stop Server), сервер останавливается полностью, автоподнятие не срабатывает.
    • Защита от бесконечного цикла крашей (Crash Loop Protection): если за короткий интервал (например, 2-3 минуты) сервер падает более 3-5 раз, автоподнятие временно прекращается, а в UI выводится критическое оповещение.
  • Счётчик падений в интерфейсе:
    • Рядом со статусом сервера (или в шапке/панели состояния) показывать бейдж со счётчиком крашей с момента старта (например: Крашей: 2).
    • При клике на счётчик открывать окно / модалку со списком последних падений с точным временем.
  • Расшифровка причин краша (Crash Explanation Engine):
    • Как парсить и определять причину:
      1. Читать свежий текстовый файл из Core/Crashes/<hash>_worldserver.exe_[date].txt.
      2. Смотреть Exception code (например, C0000005 — нарушение доступа к памяти/access violation, C0000420 — сработавший assert ядра, C00000FD — переполнение стека, E06D7363 — исключение C++ / std::bad_alloc).
      3. При C0000420 парсить блок ASSERTION FAILED (Location, Function, Condition).
      4. Анализировать последние строки Core/Logs/Server.log и Errors.log на критические маркеры (потеря соединения с MySQL, нехватка RAM/OOM, ошибка бинда портов).
      5. Проверять по встроенному словарю известных сигнатур (паттерны частых крашей с понятным описанием, например: «Сбой удаления объекта из сетки карты», «Ошибка запроса к базе данных», «Нехватка оперативной памяти»).
    • Fallback: Если сигнатура не опознана в словаре известных проблем, показывать краткую техническую выжимку (код исключения + сработавший ассерт или вершина Call Stack) и кнопку разворота полного текста крашлога / копирования.

Модули и контент

• Следующий билд: переключатель Dungeon Clear только для SQUID (запрос владельца 2026-10-31):
  • Модуль: https://github.com/Zyth45/mod-dungeon-clear, ветка coa; серверная интеграция описана в C:/games/coa-server-build/TODO.md.
  • Добавить в каталог отдельный модуль Dungeon Clear, по умолчанию выключенный. На старых серверах без модуля показывать недоступным.
  • Разрешать включение только при установленном и включённом SQUID (playerbots). При выключенном SQUID блокировать переключатель и объяснять причину; CoA Companions не подходят.
  • Проверять зависимость также в Rust backend при изменении модуля и его настроек. Отключение SQUID/переход на Companions отключает Dungeon Clear; обратное включение SQUID не включает Dungeon Clear автоматически.
  • Проверить сохранение после перезапуска, ручные конфиги и отказ включения через API в обход UI. Серверный guard обязателен независимо от Manager.
  • Все новые UI-тексты — на шести языках. После реализации добавить changelog fragments в соответствующие компоненты; пока это запланированная, не выпущенная возможность.
• Внедрение модуля гильдхаусов (mod-guildhouse):
  • Репозиторий: https://github.com/azerothcore/mod-guildhouse
  • Пайплайн сборки (coa-server-build):
    • Добавить checkout модуля в .github/workflows/server-binaries.yml, build.yml и build-linux.yml в директорию modules/mod-guildhouse.
    • Добавить лицензию модуля и копирование в scripts/assemble-tree.ps1 (Licenses/ и NOTICE.txt).
  • Адаптация под Conquest of Azeroth (CoA):
    • В диалоге дворецкого (mod_guildhouse_butler.cpp) вместо 10 классических тренеров WotLK спавнить Book of Ascension (entry 499992), которая открывает интерфейс mod-spellbook и заменяет всех тренеров для кастомных классов и прогрессии способностей.
    • Оставить без изменений: профессии, порталы в столицы, банк, аукционы (включая нейтральный), почту, вендоров, парикмахера, горн и наковальню.
  • База данных:
    • Миграции модуля (guild_house, guild_house_spawns, creature_template, gameobject_template, mod_guildhouse_locale) подхватываются coa-release автоматически при валидации схемы контракта.
  • В игре:
    • Разместить NPC-продавца гильдхаусов (.npc add 500030) в ключевых хабах / столицах (Штормград, Оргриммар, Даларан).