Usa el SDK de Node.js en AWS Lambda

1. 1.

   Instala la dependencia

   Inicializa un paquete npm en un directorio de compilación limpio. Usa npm para instalar el archivo tar oficial de https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz. Proporciona la importación @solvethree/sdk; no supongas que existe una versión publicada en el registro de npm.

2. 2.

   Configura el espacio de trabajo y el destino

   Configura variables de entorno privadas de Lambda llamadas SOLVETHREE_API_KEY, CAPTCHA_SITE y SOLVETHREE_PROXY. Usa una clave de API del espacio de trabajo, el nombre de host de destino en lugar de una URL completa y el proxy para esta tarea. El espacio de trabajo ya debe tener un perfil activo para ese sitio; consulta la configuración del perfil del sitio.

3. 3.

   Guarda y empaqueta el controlador

   Guarda el ejemplo siguiente como index.mjs. Crea un ZIP con index.mjs, los metadatos del paquete y el directorio node_modules instalado en la raíz del archivo, no dentro de un directorio de proyecto contenedor. No incluyas credenciales en el ZIP.

4. 4.

   Despliega mediante tu proceso habitual de Lambda

   Usa el entorno de ejecución Node.js 22 y establece el controlador en index.handler. Invócalo mediante tu backend autorizado o tu flujo de IAM, proporcionando un requestId estable para el trabajo lógico. Mantén privados los datos de solución devueltos.

El ejemplo usa la acción login; cámbiala por la acción que espera tu destino antes de desplegar. Envía un único proxy y usa el tipo de solicitud predeterminado enterprise-v3. No añadas los campos type ni url de reCAPTCHA.

import { Solvethree, SolvethreeError, TaskFailedError, ApiError } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
export const handler = async (event, context) => {
  const timeoutMs = Math.min(180000, context.getRemainingTimeInMillis() - 1500);
  if (timeoutMs < 1000) throw new Error('Not enough execution time to start a task');
  // The caller supplies one stable ID for this logical job; Lambda retries must
  // reuse it. awsRequestId changes with invocations and is not that logical ID.
  if (!event.requestId) throw new Error('Provide a stable requestId');
  try {
    return await client.solve({
      site: process.env.CAPTCHA_SITE, action: 'login', proxy: process.env.SOLVETHREE_PROXY,
      requestId: event.requestId,
    }, { timeoutMs, signal: AbortSignal.timeout(timeoutMs) });
  } catch (error) {
    if (error instanceof TaskFailedError) return { status: 'failed', id: error.taskId, errorCode: error.errorCode };
    if (error instanceof ApiError) return { apiError: error.status, requestId: error.requestId };
    if (error instanceof SolvethreeError) return { interrupted: true, requestId: error.requestId, taskId: error.taskId };
    throw error;
  }
};
// Invoke through your authorized backend/IAM flow. The return value is private
// solution data; do not attach this handler to an unauthenticated public URL.

El controlador lee el tiempo de ejecución restante de Lambda, reserva 1,500 milisegundos y limita la espera del SDK a 180,000 milisegundos. Ese límite corresponde a este ejemplo; no es un límite universal de ejecución de Lambda. Si queda menos de un segundo después de descontar la reserva, el controlador se niega a iniciar.

Tanto el tiempo de espera del SDK como la señal de cancelación usan el plazo límite calculado. solve crea la tarea una sola vez y la consulta periódicamente hasta que esté lista o se produzca un error. La reserva deja tiempo para que la gestión de errores devuelva información de recuperación, pero una terminación forzada de Lambda puede impedir que se devuelva cualquier respuesta.

El código que realiza la llamada debe conservar event.requestId entre los reintentos de invocación. Usa entre 1 y 64 letras ASCII, números, guiones bajos o guiones. No uses awsRequestId: identifica una invocación, no la solicitud lógica de resolución.

Los errores de validación y los errores inesperados se vuelven a lanzar. El controlador no convierte todas las excepciones en una respuesta de interrupción.

1. 1.

   Recupera mediante el ID de tarea cuando esté disponible

   Consulta la tarea existente con getTask. pending y solving indican que sigue en ejecución; solo ready contiene una solución utilizable. Mantén cualquier espera adicional dentro del tiempo restante de la nueva invocación.

2. 2.

   En caso contrario, recupera mediante el ID de solicitud lógica

   Reintenta la misma solicitud de tarea con el requestId original del cliente que la envió. Si los parámetros coinciden, se devuelve la tarea existente; si son distintos, se produce un conflicto. Mantén el sitio, la acción y el proxy sin cambios durante la recuperación, incluso si cambia la configuración.

Un tiempo de espera de conexión agotado no demuestra que la creación de la tarea haya fallado. Recupera la tarea existente antes de asignar un nuevo ID de solicitud lógica. Consulta los contratos correspondientes en consulta periódica de tareas y gestión de errores de la API.

El SDK devuelve los datos de la solución; no los aplica al destino. Cuando tu aplicación los envíe, usa el proxy configurado y los valores userAgent y secChUa devueltos. No los sustituyas por una identidad de navegador o una URL de destino ajenas. Una tarea lista significa que se ha generado una solución, no que el destino haya aceptado la solicitud posterior.