Платформа

Надёжность долгоживущего BrowserContext

Проектируйте восстановление контекста после сбоев браузера, сетевых перерывов и обслуживания с сохранением владельца данных и согласованности.

Документация

Нужна структурированная документация по теме Платформа?

Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.

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

Цикл согласованного восстановления браузерного контекста

Контекст как аренда с владельцем

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

Используйте состояния planned, starting, active, degraded, draining и closed. Переходы должны быть идемпотентными, потому что уведомление о закрытии может прийти повторно. У аренды есть срок и правило продления. Когда продление прекращается, планировщик останавливает новые задачи и начинает согласование.

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

Разделяйте намерение и изменяемое состояние

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

Записывайте контрольную точку вместе с версией аренды. Конфликт версии должен вести к согласованию, а не к повторному выполнению. Cookie, local storage, загрузки и черновики имеют разные правила хранения. Сохраняйте только то, что разрешено политикой и действительно можно восстановить.

Предсказуемый запуск и восстановление

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

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

Управляемое восстановление после сбоя

После сбоя отметьте аренду как degraded и остановите новые задачи. Сохраните несекретные сведения: версию, поколение, последнюю контрольную точку и состояние хоста. Если в группе есть другие контексты, владелец группы решает, локальна ли проблема.

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

Ограниченные сетевые повторы

Запрос, длительное соединение и канал управления являются разными классами сбоев. Фиксируйте класс, ограничивайте число попыток и добавляйте задержку. Чтение иногда можно повторить, а запись или отправка требуют подтверждения приложения.

Повтор остаётся в разрешённом маршруте. Если смена маршрута меняет региональную идентичность, закройте аренду и создайте новую сессию. После исчерпания бюджета отметьте восстановимую ошибку и возвращайте ресурс только после очистки.

Переработка на границе политики

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

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

Проверка согласованности

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

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

Публичный объём проверки согласованности доступен в BotBrowser Proof Center. Руководство по памяти BrowserContext и материал о масштабировании контекстов дополняют эту практику.

Операционный список

  • У аренды есть владелец, срок и повторяемые переходы.
  • Профиль, хранилище, маршрут и версия назначаются до работы.
  • Контрольные точки не содержат секретов.
  • Сбои и повторы ограничены бюджетом.
  • Переработка подтверждает очистку до возврата ресурса.
  • Тесты сравнивают структурированные записи и проверяют закрытие.

При сомнении в собственности или очистке остановите приём и сначала выполните согласование. Браузер может перезапуститься, а worker замениться, но сервис должен объяснить, какая привязка была активной, что подтверждено и почему создан новый контекст.

#Browser Context#Resilience#Recovery#согласованность#автоматизация#Lifecycle

Переведите BotBrowser из исследований в продакшн

Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.