Ломается генерация проекта, если на бэке в БП вэбсокета стоит дисконнектор
job error: [{“level”:“error”,“meta”:“container exit with code 1. Logs: \u0002\u0000\u0000\u0000\u0000\u0000\u00000go: added GitHub - richardlehane/mscfb: golang reader for the Microsoft Compound File Binary File format v1.0.4\n\u0002\u0000\u0000\u0000\u0000\u0000\u00002go: added GitHub - richardlehane/msoleps: Reader for MS OLE Property Set format v1.0.4\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000/go: added GitHub - tiendc/go-deepcopy: Fast deep-copy library for Go v1.6.0\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000%go: added GitHub - xuri/efp: Go Language Microsoft Excel™ Formula Parser v0.0.1\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000-go: added github.com/xuri/excelize/v2 v2.9.1\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000%go: added GitHub - xuri/nfp: Go Language Microsoft Excel™ Number Format Parser v0.0.1\n\u0002\u0000\u0000\u0000\u0000\u0000\u00003go: upgraded The Go Programming Language v0.14.0 =\u003e v0.25.0\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000\u001c# appmaster.io/app/services\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000_services/wsson_receive_chart_scale_10.go:52:38: undefined: systemBP.WSSDisconnectChartScaleOut\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000^services/wsson_receive_chart_scale_10.go:80:37: undefined: systemBP.WSSDisconnectChartScaleIn\n\u0002\u0000\u0000\u0000\u0000\u0000\u0000]services/wsson_receive_chart_scale_10.go:197:54: undefined: systemBP.WSSDisconnectChartScale\n”}]; runtime error:
ПС после закрытия клиентом соединения блоком вэба WSS:Disconnect, бэк еще минуту-две продолжает показывать success = true на выходе блока WSS Send. Из-за чего не получается остановить БП и он продолжает слать сообщения в закрытый канал.
ПСС Не нашел чем проверять на бэке статус WS соединения
@Konstantin Здравствуйте, проблему публикации зафиксировали. Информация передана разработчикам
@Konstantin Можете показать, как у вас реализована логика работы вебсокетов на фронтенде и бэкенде?
Здравствуйте.
БП Фронта
-по этому клику запускается или разрывается соединение
-это общий триггер приема сообщения
БП бэка (луп проверяет изменения в БД - это решение для тестов пока. Здесь ломается публикация если disconnect поставить на выход лупа)
Прошу также подтвердить, что это должно работать в сафари. В отличие от хрома у меня пока не получается увидеть получение сообщений в логах, видно только __ping. И перемежается это все вот такой ошибкой
@leryq_it Добрый день. Не пойму все-таки по сафари - в консоли вообще ответов сервера в сокет соединении не видно. Вот для сравнения один и тот же алгоритм параллельно запущенный из 2 браузеров. В хроме прилетают обновления данных, а в сафари нет. Это баг или какие-то особенности в сафари?
@Konstantin Должно работать идентично по всех браузерах без исключения. Есть шанс что в мобильных браузерах будет больше реконнетов из-за энергосбережения, но точно должно работать в любом современном браузере.
Мы со своей стороны проведем тесты дополнительно в разных браузерах и ОС. Судя по тому что сокет соединение устанавливается, базовый функционал работает. Перероверьте логику в бэкенде, что вы шлете сообщения с бэкенда в правильное соединение.
Появилось немного времени для тестирования вэбсокетов и столкнулся со следующим:
-
в сафари не работает. В консоли видно пинги, а понгов и сообщений сервера не видно, бизнес-процесс фронта, соответственно, не запускается. БП бэка видит, что соединение открыто и работает нормально.
-
в хроме работает, но тормозит процесс disconnect. При попытке дисконнекта соединение как-то “ломается” сразу - в консоли начинают сыпаться ошибки о том, что соединение разорвано и процесс на on_receive больше не запускается. Но бэк поломанного соединения сразу не видит и продолжает слать сообщения. В моем тестировании около 70 секунд. Потом бэк обнаруживает поломанный канал и останавливает БП. Флоу на фронте на это время залипает на блоке WS disconnect.
-
если просто закрыть страницу браузера, то бэк никогда не увидит закрытое соединение и будет выполнять свой БП до полного окончания и только потом выведет ошибку в лог о закрытом сетевом соединении. Может это нормально, но хотелось бы иметь на бэке инструмент проверки текущего статуса, чтобы отключать ненужные БП. (Это тестировалось из сафари, при параллельно открытом хроме, висящем на том же ip, естественно)
Как реализовано тестирование.
На бэке БП висит на Connect (посылает тесктовое сообщение прирастающее в цикле, спустя 500 секунд дисконнектится)
На фронте соединение запускается и разрывается по кнопке
При получении сообщения обновляется текстовое поле
Страница для тестирования SunPeak
@leryq_it Алексей, проверьте, пожалуйста на этой странице. Может я что-то не так делаю?
Upd: кажется в ходе тестирования перезагрузился сервер в момент недоступности WS соединения
@Konstantin Здравствуйте, приносим извинения за длительное ожидание ответа. Проверили работу WebSocket в Safari — подтверждаем проблему с отсутствием pong от сервера. Информацию передали команде разработки.
@Konstantin Проблема в том как Safari работает с компрессией сообщений (per-message-deflate): он ее анонсирует, но не умеет корректно с ней потом работать.
Сделали временный фикс для региона, в котором развернуто ваше приложение. Должно заработать в Safari, в остальных браузерах сжатие пакетов продолжит работать.
В течении недели сделаем полноценный фикс на уровне кода бэкенда чтобы браузеру Safari не позволял использовать компрессию.
Несмотря на то, что ваш тест заработал и в консоль приходят сообщения + отображаются на вашей страничке, в Developer Tools по прежнему только пинги на сервер.
Работает, спасибо! И еще 2 и 3 замечание также актуально - нужно иметь возможность проверки состояния соединения с сервера, чтобы отключать невостребованные бизнес-процессы бэка. Потому что сейчас при многократном входе-выходе на/со страницы, где включается вэбсокет, происходят странности: бэк запускает БП connect по количеству заходов на страницу, а дальше шлет данные всех этих параллельных одинаковых БП в последнее включенное соединение.
