У функции с HTTP-триггером есть 230 секунд на ответ, что бы ни было указано в functionTimeout, а тайм-аут опроса для reCAPTCHA по умолчанию равен 300. Разбираем, где на самом деле должно происходить решение капчи и какой режим подключения реально нужен приложению-функции в Azure.

ALTCHA представляет собой задачу на хеширование, а не картинку, поэтому Python решает её без браузера и за миллисекунды. Разбираем сам вызов, два способа передать задачу и то, как обработать пакет так, чтобы задачи не устаревали.

ALTCHA построена на доказательстве работы, поэтому распознавать нечего, а решение детерминировано. Разбираем вызов на C#, два способа передать задачу и то, почему token нужно отправлять обратно байт в байт.

BullMQ по умолчанию выполняет одно задание за раз, а у воркера, который блокирует event loop, задание забирают и решают повторно. Разбираем настройки, которые определяют и то и другое, и то, где должен слушать решатель.

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

Trigger.dev собирает вашу задачу в Docker-образ и запускает её на своей инфраструктуре, поэтому 127.0.0.1 внутри задачи никогда не указывает на ваш компьютер. Разбираем, какой режим подключения работает и какой тайм-аут незаметно обрывает медленное решение капчи.

Исполнитель кода в Retool по умолчанию блокирует частные адреса, поэтому блок кода не может достучаться до решателя в вашей LAN, а блок REST-ресурса может. Ниже разобран весь сценарий вместе с тайм-аутами блоков, от которых зависит, переживёт ли медленное решение капчи.

В Selenium Grid браузер находится на одной машине, а код теста на другой, и в решении капчи это меняет ровно одну вещь: откуда должен быть доступен решатель. Ниже разобраны настройка RemoteWebDriver, подстановка токена и тайм-аут сессии узла, который незаметно обрывает медленное решение.

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

Locust учитывает в статистике всё, что отправлено через self.client, поэтому решение капчи там попадает в ваши перцентили. Ниже разобрано, где должен стоять вызов, почему test_start срабатывает один раз на узел, а не один раз на запуск, и когда один токен на пользователя лучше одного токена на тест.