Диагностика и восстановление

1. Что фиксируется локально

При включённом crash reporting единый manager обрабатывает необработанные Python/thread exceptions и включает faulthandler для части native failures. В runtime-каталоге логов сохраняются:

• session.json — идентификатор и состояние сессии;
• exception.json — структурированное исключение, если оно было;
• faulthandler.log — доступная native/thread диагностика;
• runtime logs и дополнительные файлы конкретной crash session.

Настройки РАЗРАБОТЧИКУ → Логирование имеют разное время применения. Root level, module-prefix filters и основной file handler перестраиваются сразу для текущего desktop-процесса. Параметры crash manager — enabled, native/all-thread capture, session log и retention — читаются при инициализации и полностью вступают в силу после перезапуска. Startup prompt тоже относится к следующему запуску.

• Применять автоматически по умолчанию включён при каждом создании страницы и не сохраняется. Если его выключить, controls остаются черновиком до Применить сейчас; Перечитать из файла отбрасывает черновик.
• Основной logging.to_file и crash-session session.log — разные handlers. Выключение первого в текущем запуске не закрывает уже установленный session handler.
• Module flags фильтруют logger-name prefixes, а не выключают функцию программы. Они применяются к текущему process; отдельные tools/children имеют собственную startup logging configuration.

2. Diagnostics bundle

1. Откройте блок Crash Reports на странице «Логирование».
2. Нажмите Обновить состав. Preview показывает источник, число файлов, общий размер и до 200 archive paths; это manifest, а не просмотр содержимого. Если элементов больше, ZIP всё равно включает полный список.
3. При необходимости откройте каталоги logs/crash reports и изучите исходные файлы.
4. Экспортировать diagnostics bundle создаёт локальный ZIP в выбранном месте.

В архив добавляется diagnostics_report.json с json_role=diagnostics_report, version и списком файлов/размеров. При наличии незакрытого прошлого report страница выбирает его раньше текущей session. Bundle включает дерево выбранного crash-report и top-level .log/.txt из ScrephData/logs. Проект, autosave, models и вложенные каталоги других компонентов автоматически не прикладываются, хотя логи могут содержать их пути или имена.

3. Ручная отправка

• Upload не выполняется молча. Нужны авторизованный аккаунт и нажатие Отправить на сервер либо отдельное согласие в startup prompt. Ручная кнопка сама собирает временный ZIP; предварительный локальный export не обязателен.
• Logging page показывает manifest. Startup prompt показывает тип/текст ошибки, время и локальный report path, но не список файлов или размер; после «Да» сразу начинается сборка и отправка. Для проверки выберите «Нет», откройте Logging и отправьте вручную. Один и тот же report после показанного prompt повторно автоматически не предлагается.
• В multipart входят ZIP, необязательная note, source и metadata среды: platform, Python version, mode, current working directory, session ID и полный local report path. Поле client_version присутствует в protocol, но текущие desktop callers оставляют его пустым; app version находится в session.json.
• Сервер принимает только непустой файл с именем .zip до 25 MB, сохраняет исходный archive и SHA-256, а также записывает account, IP и User-Agent. Автоматического срока удаления server diagnostics сейчас нет.
• Перед ручной отправкой просмотрите preview и при необходимости исходные файлы: runtime logs или crash artifacts могут содержать пути, названия проектов и другие сведения рабочего окружения.
• При отсутствии auth token, bundle или сети операция завершается явной ошибкой; локальный экспорт остаётся доступным.

4. Восстановление проекта

Crash report не заменяет autosave проекта. Selector ведёт отдельный канонический autosave_session.json, а Capture — собственный recording autosave. При старте Selector принимает autosave, если восстановились elements/edges или хотя бы base image. Capture сначала пытается вернуть saved media timeline, затем newest close_autosave_*, и ничего не подменяет, если timeline уже непустой.

Через Файл → Загрузить проект можно открыть Project Manager, выбрать вкладку Автосейвы и скопировать всю папку autosave в отдельный проект под новым именем. Но Manager разрешает это только для autosave с ненулевым domain count; screenshot-only recovery остаётся startup-only границей текущего UI.

Если autosave при закрытии не записался, Screph не скрывает ошибку и запрашивает решение о закрытии. Project Manager отделяет неоткрываемые exports и повреждённые JSON в «Проблемные», но его pre-open diagnostics не являются свежей полной artifact-integrity проверкой. После загрузки более подробный domain load report и сохранённые save diagnostics появляются в InfoPanel.

Сохранение, Project Manager и autosave →

5. Границы

• Ни один crash handler не гарантирует перехват любого аварийного завершения.
• Support helper и Screph Code/Pro Agent используют отдельные процессы. Automation Manager UI в обычном Selector flow создаётся внутри desktop-процесса, но запускаемый им сценарий — отдельный Python child. stderr/stdout и журналы child могут отличаться от main desktop log; сбой child не обязательно создаёт crash session главного окна.
• Остановка прямого Automation Manager child не гарантирует завершение процессов, которые запустил сам сценарий. После аварии проверьте Task Manager, целевые приложения и неожиданные loopback listeners.
• Bundle помогает диагностике, но не является backup проекта.
• Restore autosave создаёт отдельный проект копированием всей autosave directory; проверьте source paths, artifacts и лишние соседние файлы перед продолжением.

Если отдельный компонент не запускается, сначала зафиксируйте его command/runtime readiness, PID или exit code и соответствующий log, а уже затем перезапускайте main desktop. Карта process boundaries приведена в архитектурной справке.