Баги, которые вы никогда не встретите

Продолжаем серию статей с VK Tech Talks. В этот раз презентуем новосибирский доклад Тимофея Чаптыкова про баги.

В начале своего доклада Тимофей решил поведать слушателям три истории. Три истории про три бага, с которыми сталкивался непосредственно он сам.

Перейдём к первой истории.

Из-за наличия в первой части названия слова «иногда» Тим не хотел обращать внимания на тикет, но вторая часть даёт понять, что проблема действительно заслуживает внимания и что это крайне критичный сценарий.

При виде тикета у Тима в голове возникает мысль, что «это какая-то дичь».

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

Далее нам необходимо понять: что же такое активные действия пользователя?

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

Через некоторое время тестировщики смогли найди способ стабильного воспроизведения данной проблемы. Он насчитывал 11 шагов и занимал около двух минут.

Выяснилось, что Chrome говорит, что пользователь двигает курсором мыши в неактивной вкладке ещё и с отрицательными координатами. Естественно, Chrome обладает своими проблемами, но Тима это не остановит, и он сделал следующее, после чего ушел на обед:

После того, как он вернулся, стали возвращаться положительные координаты. Пришлось разбираться подробнее, что это за координаты и откуда они берутся.

Предлагаем Вам посмотреть короткий фрагмент выступления, объясняющий, что вышло по итогу:

Сделаем выводы:

Проблема решилась отказом от mousemove и переходом на mouseover.

Пришло время поговорить о второй истории.

Внешне очень похоже, что эта проблема связанна с данными: на сервера приходят лишние события, backend дублирует это и прочее. И снова нужно как-то решать эту проблему.

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

Однажды коллега Тимофея подходит к нему с хитрым лицом, показывает кусок кода и спрашивает: «Чему равно?»

Зная javascript, можно с уверенностью сказать, что ответом будет число 2. Также считает и большинство браузеров.

Кроме одного — Safari Technology Preview:

Выяснилось, что это действительно проблема с их стороны. Браузер брал рандомное число 336, до него всё заполнял null и вставлял 1000. После чего честно говорил, что в таком объекте у него 338 ключей.

При каких условиях воспроизводится этот баг? На самом деле он воспроизводится из-за значения:

0.1 не входит в диапазон int32. Это не единственный кейс.

Например, timestamp. Во «ВКонтакте» использовался именно timestamp, из-за чего всё ломалось и получались объекты с невероятно большим количеством ключей для определенной версии Safari.

Как починили этот баг?

Timestamp просто перестали хранить как число, и стали хранить как строку.

И вот последняя, третья история.

Что такое фастчаты?
Каждому из нас так или иначе приходилось с ними сталкиваться.

А зачем вообще переводить фастчаты на лонгполл?

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

Теперь про график. Как читать график ошибок JS?

Обычно на нём сравниваются текущее положение вещей по времени, количество ошибок в сравнении с другим днём, который на него похож.

Что делать в этой ситуации? Тим решил, что лучше написать, что всё нормально. Число ошибок начало уменьшаться, но до сих пор на 60 % превышало норму. Однако Тимофею всё равно казалось, что это не похоже на проблему с кодом.

Какую Тим искал ошибку? А вот такую:

Проблема заключалась в том, что стектрейс смотрит в совершенно случайное место. Перспектив найти эту ошибку практически нет.

Ошибки продолжали приходить до конца дня.

Докладчик всё еще не отказывается от своей теории, что его код тут ни при чём.

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

Графики пришли в норму, но всё еще непонятно, почему это сработало.

Сделаем некоторые выводы:

1. «ВКонтакте» имеет действительно много пользователей. В этом случае теория вероятности начинает работать против вас. Невозможные события становятся для вас ежедневным и нормальным делом.

2. «ВКонтакте» — очень личное пространство для пользователя.

Что с этим делать?

Вот и всё!

Посмотреть полную версию доклада можно в трансляции мероприятия:

Автор: Сергей Котов
Корректор: Арсений Метелев