Сидим в офисе, примус починяем, редакция разослала пуш. Ну пуш и пуш, но на 2 из 20 телефонов он приходит без картинки. Разработчики что-то там мычат невнятное, что картинка же с cdn грузится, надо ковырять cdn в первую очередь. Ну ок, берем сырые логи cdn, видим все валидные ответы, 200 rps примерно, но не больше - смутило. И пара ответов были с некорректным размером. Ну врядли же это были именно ответы нам. И правда, не нам. На этом этапе еще обратили внимание, что 90% запросов за этой злополучной картинкой, которая не загрузилась, с юзерагента okhttp. Ну ок, копаем дальше. Сам хост внешнего сдн записан как альяс в нашем днс, т.е. появилась мысль, что у нас что-то с днс, что телефоны не могут отресолвить. Но по графикам не видно чтобы рассылка пушей сопровождалась прям существенным увеличением запросов к нашему днс, видимо все же где-то кешируется. А какой-нибудь dnsperf по тем же самым графикам провоцирует сильно бОльшую нагрузку, с которой справляемся. Остается все же приложение, и наши разработчики, которые клянутся, что лучшие практики и вообще копипаста из примеров гугла. Тем не менее, тратим релиз на то, чтобы начать логировать ошибки и в этом месте, и получаем при следующем пуше ошибку (!) что хост сдн не может отресолвиться. Иногда. На разных телефонах, но чаще как будто на китайских..ну и в общем через пять минут мы уже находим прекрасный тикет 2018 года библиотеки okhttp, уходящие корнями на уровень OS Android. Получается, эта проблема косвенно имеет отношение и к энергосберегающим политикам, и к детекции смены сети, и существует ооочень давно, но врядли в каких-то ситуациях важна (кроме как в нашей, когда телефон спит и первое что он получает - пуш, а потом он делает первый запрос за картинкой, и все это происходит в первые две секунды, когда сетевой стек в несознанке, оказывается, находится). Удивительное рядом.