
В моём приложении для чтения состава был баг, который выглядел как проблема с интернетом. Человек фотографирует упаковку, ждёт, а телефон говорит: «Нет связи». Хотя связь есть. Сервер тоже жив. Все здоровы, кроме пользователя.
По началу я грешил на память и перезапуски. Проверил — нет. Оказалось, распознавание большого фото занимало больше времени, чем клиент был готов ждать. Телефон уже показал ошибку, а сервер ещё честно разбирал мелкий текст на пачке. В итоге один думал «запрос провалился», второй — «я всё сделал». Семейная ссора, только между двумя программами.
Исправили без покупки нового сервера:
перед отправкой дали обрезать фото до самого состава — ценник и соседняя полка OCR мало помогают;
на сервере уменьшили длинную сторону снимка до 1600 пикселей и вынесли распознавание из основного цикла через
asyncio.to_thread;клиентский таймаут подняли с 20 до 45 секунд. Но только таймаутом дело бы не вылечилось, пользователь просто ждал бы подольше.
На телефоне проверили: распознавание доходит до результата, старое «Нет связи» не вылезает. Красивой таблички «было 63 секунды, стало 4» не будет — до исправления я замеры не записал. Очень предусмотрительно, да.
Главный вывод у меня теперь простой: «Нет связи» не всегда про сеть. Иногда это просто сервер который слишком старательно читает состав, пока клиенту уже надоело ждать.
Про само приложение — «Этикетку» — недавно написали в блоге RuStore: https://www.rustore.ru/prostore/etiketka-sostav-produktov Интересно почитать, у кого то же было примерно такое, что таймаут притворялся проблемой с интернетом?
divinity2000
Это шутка? Все настолько обленились что доверяют иишке абсолютно всё? Неужели так сложно сделать нормальную фоновую операцию с тремя условными статусами типа processing, complete и error, и пускай OCR хоть сутки разбирает пиксели? Зачем вообще таймауты на клиенте?