Guzzle Pool: pasa el proxy de cada tarea a requestAsync

Coloca el proxy de cada tarea de Guzzle en la operación asíncrona que inicia el pool. Dentro de una configuración de cliente existente, usa fábricas de promesas:

$operations = function () use ($client, $jobs) {
    foreach ($jobs as $id => $job) {
        yield $id => function () use ($client, $job) {
            return $client->requestAsync('GET', $job['url'], [
                'proxy' => $job['proxy'],
                'timeout' => 20,
            ]);
        };
    }
};

$pool = new GuzzleHttp\Pool($client, $operations(), [
    'concurrency' => 4,
]);
$pool->promise()->wait();

Cada tarea validada aporta un destino y un proxy. Para una petición pública permitida, un candidato HTTP de la lista de proxies HTTP puede aportar la URL de proxy sin credenciales de esa tarea; la selección ocurre antes de que se ejecute su fábrica. Una petición PSR-7 describe el mensaje HTTP, mientras que estas opciones de envío controlan el transporte. Imprimir o guardar un valor de proxy junto al mensaje no puede configurar una operación que lo envía de otra manera.

Devuelve requestAsync() desde la fábrica. Llamar a request() síncrono allí puede bloquear mientras el pool intenta iniciar trabajo concurrente.

Añade callbacks de cumplido y de rechazo usando el manejo existente de la aplicación. Conserva la clave de la tarea, el identificador del proxy elegido y el número de intento en ambos resultados; el orden de finalización difiere del orden de entrada. No elijas en secreto otro extremo en la fábrica después de registrar uno para la tarea.

El valor de concurrencia limita el trabajo de este pool. Varias tareas que eligen un mismo proxy o cuenta limitada pueden seguir necesitando un presupuesto aparte para ese extremo.

Interpreta los resultados por etapa: el rechazo del destino, la autenticación del proxy y el tiempo de espera de conexión son resultados distintos. Las opciones de envío conservadas con la tarea muestran qué ruta produjo cada resultado.