Блокировки и восстановление записывающих писателей Conversations

Обновленные демоны могут совместно использовать Conversations и параллельно работать с разными сессиями. Загруженная сессия по-прежнему имеет одного записывающего писателя. Активная активация принадлежит исключительно издателю стабильного Live-локатора; потеря публикации Live не отключает автономные диалоги.

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

session_writer_conflict означает, что writer fence заблокировал доступ. Это может означать, что другой процесс открыл диалог, или что остаточную блокировку нельзя безопасно вернуть. Это не доказательство того, что другой писатель сейчас активен. session_writer_unavailable означает, что принадлежность не удалось подтвердить; повторные попытки не дают права обходить эту проверку. Archive и delete могут вернуть HTTP 200 с ошибкой писателя для отдельной сессии. Проверяйте каждый элемент результата.

Закройте диалог штатно в владеющем процессе Qwen, затем используйте Try again в затронутом диалоге. Можно продолжать работать с другими сессиями. Не создавайте диалог-замену просто чтобы ошибка исчезла.

После некорректного завершения работы перезагрузка Linux или перезапуск контейнера в новое пространство имён PID может оставить незапечатанную активную запись писателя навсегда заблокированной через fence. Выжившего владельца, который мог бы закрыть её, может не быть. Следуйте Operator recovery for a residual lock вместо многократных повторных попыток; этот релиз не выполняет автоматический захват через такие границы идентичности.

Если проблема сохраняется, включите локальную отладочную запись (QWEN_DEBUG_LOG_FILE=1) при запуске затронутого демона и изучите diagnostics демона и дочернего процесса ACP. Diagnostики получения аренды включают ID сессии, тип ошибки и точный lockPath, разрешённый из runtime-хранилища этого писателя. Не угадывайте путь блокировки по основному рабочему пространству или домашнему каталогу по умолчанию. Публичные ошибки HTTP/ACP намеренно не раскрывают пути и записи о владении. Держите диагностические файлы в тайне; не публикуйте токены владельца или неразвёрнутое содержимое блокировок.

Какие состояния могут восстановиться автоматически?

Эти правила применяются к арендам писателей сессий. Устаревшие глобальные записи владельца используют более ограниченную проверку совместимости, описанную ниже.

• Штатное закрытие освобождает аренду. Сертифицированная запечатанная передача принимается только если доказательство транскрипта всё ещё действительно.
• Мёртвый активный писатель может быть возвращён только если существующие проверки идентичности устанавливают, что его процесс принадлежит той же подтверждённой области действия liveness.
• Живые или зависшие писатели остаются под fence. Убийство демона недостаточно, если его дочерний ACP-писатель выжил.
• Чужеродная или отсутствующая идентичность boot/пространства имён процессов не является доказательством смерти. Отсутствующий PID в вашем пространстве имён не доказывает, что чужой писатель завершился.
• Искажённые записи, неопределённая идентичность транскрипта и остаточные захваты перехода fail closed. Одно лишь прошедшее время никогда не даёт права на захват.

Восстановление оператором остаточной блокировки

1. Определите точную затронутую сессию и хранилище по локальным диагностическим данным. Сохраните лог сбоя и приватную резервную копию транскрипта и артефактов блокировки. Зафиксируйте, какие бинарные файлы и хосты могут обращаться к этому хранилищу.
2. Остановите или возьмите под fence каждого возможного писателя, включая отсоединённых дочерних процессов ACP, другие демоны, контейнеры, пространства имён и машины, разделяющие файловую систему. Подтвердите fence с соответствующего хоста/пространства имён. Если не можете обеспечить это, остановитесь и обратитесь к оператору, который может.
3. Изучите точную запись и связанные артефакты захвата/вывода вместе с сопровождающим. Определите, являются ли последний транскрипт и доказательство передачи авторитетными. Не редактируйте поля идентичности владельца, чтобы искусственно создать совпадение.
4. Только после того как писатели взяты под fence и доказательства сохранены, переместите индивидуально проверенные остаточные артефакты в приватное хранилище восстановления под надзором оператора. Никогда не удаляйте рекурсивно каталог блокировок и не снимайте все блокировки.
5. Запустите один обновлённый демон, восстановите исходную сессию и проверьте её последний записанный ход перед добавлением. Сохраняйте резервные копии до подтверждения непрерывности. Верните остальные обновлённые демоны только после этой проверки.

В этом релизе нет API принудительной разблокировки или автоматического захвата между загрузками/TTL. Когда безопасное владение не может быть установлено, сохраняйте fence.

Скоординированное обновление и откат

Переключение backend и изменения локальных ошибок/повторов Web Shell должны выйти в одном релизе. Это не смешанное rolling-обновление: старые демоны могут создать глобального владельца после того, как обновлённый демон уже запущен.

Перед обновлением выполните дренирование всех старых сессий и запланированных задач, остановите все старые демоны и их дочерние процессы ACP, сохраните runtime-данные и только после этого запускайте обновлённые бинарные файлы. Обновлённый демон, столкнувшийся с живым устаревшим владельцем, вернёт 503 conversation_runtime_in_use; после выхода этого владельца повторите попытку без перезапуска. Только точно повторно подтверждённая устаревшая запись выводится из эксплуатации. Искажённое или небезопасное устаревшее состояние требует расследования оператором.

Устаревшая запись conversations/runtime-owner.json содержит PID и nonce, но не содержит hostname, boot ID или идентичность пространства имён PID. Её проверка совместимости может лишь проверить, существует ли этот PID в собственном хосте и пространстве имён PID обновлённого демона. Она не может обнаружить старого писателя, работающего в другом месте на общем хранилище. Это ещё одна причина взять под fence каждого возможного писателя перед запуском обновлённого демона; проверка не делает смешанные обновления между хостами или пространствами имён безопасными.

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