ADR 0039: восстановление процесса после потери владения

Статус: принято.

Проблема

Аварийный перезапуск PostgreSQL закрывает session advisory lock API. Каталог навсегда помечает старого владельца неактивным. Это правильно запрещает публикации после потери блокировки, но HTTP-процесс оставался живым с постоянным 503, поэтому системный supervisor не мог восстановить сервис.

Решение

Production entrypoint API подключает lifecycle callback потери владения. Проверка раз в секунду читает только необратимый признак ApiRuntime.available; ошибки обычной readiness, заполненный диск и единичные SQL-ошибки не являются поводом для перезапуска. После потери storage claim или download lease callback вызывается один раз.

Процесс выставляет код завершения 1, прекращает приём работы, отменяет передачи и закрывает ресурсы штатным app.close. При незавершённом shutdown процесс принудительно завершается через 120 секунд. Системный supervisor запускает новый процесс, который заново проходит всю проверку storage identity, блокировок и leases. Старое владение не восстанавливается внутри живого процесса и fencing не обходится.

Embedding через createServer по умолчанию сохраняет fail-closed 503: владелец процесса сам передаёт onOwnershipLost. HTTP-обработчики и infrastructure не вызывают process.exit. Проверяющий timer удаляется первым preClose hook, чтобы штатное обслуживание не считалось аварией.

Проверки и последствия

PostgreSQL integration принудительно закрывает соединение владельца, проверяет единственное уведомление, закрытие listener, повторный чистый старт и отсутствие recovery при штатном close. Native/container acceptance аварийно останавливает реальную БД и требует самостоятельного возвращения API readiness. Передачи могут оборваться; клиенты используют resume/retry. Это восстановление после fencing, не watchdog зависшего event loop и не HA.