Закрытие WebSocket и судьба последней записи
Во время обслуживания сервер корректно закрывает WebSocket. Клиент видит нормальное завершение и удаляет последние измерения из очереди. В архиве части записей нет. Ошибка может находиться в прикладной трактовке закрытия: протокол завершил соединение, но не сообщил, какие операции успели пройти согласованный этап обработки. Для выгрузки нужна отдельная модель результата каждой записи.
Не расширять значение Close
RFC 6455 определяет процедуру закрытия и коды состояния WebSocket. Они описывают завершение соединения в протокольном контексте, а не общий транзакционный итог всех прикладных сообщений. Следовательно, даже ожидаемый код закрытия не заменяет согласованную квитанцию архива. (IETF RFC 6455 — WebSocket messages and control)
Перед испытанием перечисляют состояния записи: подготовлена, поставлена в отправку, передана библиотеке, подтверждена на нужном этапе. Если приложение использует меньше состояний, их границы всё равно должны быть ясны. В журнале сохраняют идентификатор последней подтверждённой записи и список оставшихся неопределёнными. Само событие Close записывают отдельно с исходным временем и причиной.
Проверить несколько точек завершения
На стенде сервер штатно закрывает соединение до отправки учебного документа, после его получения и после предусмотренного подтверждения. Наблюдают очередь клиента и результат у получателя. Между случаями не меняют формат данных и правила повторов: задача состоит в выявлении связи между закрытием и прикладным состоянием, а не в общем тесте всех компонентов.
Для неопределённого результата применяют утверждённую процедуру сверки либо повторной отправки с контролем дубликатов. Повтор не должен автоматически означать второе физическое событие. Если операция меняет исполнительное состояние, её контракт требует отдельной проверки; перенос правил простого архива на управление без согласования недопустим. Для редакционного примера используют только учебные измерения.
Сделать восстановление объяснимым
После повторного подключения сравнивают число исходных документов, подтверждённых результатов и сохранившихся неопределённостей. В интерфейсе не следует показывать «всё отправлено» лишь по отсутствию активного соединения. Оператору нужен различимый статус ожидания сверки, если данные могли быть приняты, но квитанция потерялась. Конкретные сроки и действия определяет владелец системы.
В акте перечисляют испытанные точки закрытия, наблюдаемые коды и судьбу каждой учебной записи. Приёмка завершена, когда закрытие не удаляет неподтверждённые данные без предусмотренного основания, а восстановление даёт согласованный результат. Это позволяет безопасно проводить обслуживание WebSocket-сервера и не превращать корректное завершение транспорта в скрытую потерю последних измерений полевого узла.
Запросы отправляются на наш e-mail из вашей почтовой программы.
