Tres incompatibilidades en Playwright y Apify que cuestan horas de depuración

Un desarrollador que ha desplegado un Actor en Apify para monitorizar datos gubernamentales ha publicado un desglose de tres errores no documentados que surgieron al combinar Playwright con Camoufox. No son fallos críticos de seguridad, pero sí problemas de integración que pueden bloquear la ejecución de scripts de automatización durante horas. El objetivo del post es ahorrar tiempo a quienes enfrenten los mismos muros en sus pipelines de scraping.

Incompatibilidad de versiones y cuelgues en la interfaz

El primer problema surgía al lanzar el navegador: Playwright 1.61 introdujo un campo isMobile en la llamada de protocolo Browser.setDefaultViewport que la capa Juggler de Camoufox no reconocía. La imagen base oficial de Apify, apify-python-playwright-camoufox:3.14-1.61.0, sugería de facto usar Playwright 1.61, pero esa versión era la rota para esta combinación. Fijar la dependencia en playwright==1.60.0 resolvió el error inmediatamente. La lección operativa es clara: las etiquetas de las imágenes base de contenedores no siempre garantizan compatibilidad entre dependencias pares; hay que verificar la matriz de versiones real.

El segundo fallo era intermitente: Locator.click() en campos de texto podía colgarse indefinidamente bajo conexiones de proxy residencial con latencia irregular. Al cambiar a locator.fill(value), que enfoca el elemento sin despachar un clic de ratón explícito, los cuelgues desaparecieron. Aunque no se identificó la causa raíz exacta, fill() resulta más robusto para entradas de texto al reducir la dependencia de la resolución de coordenadas y el z-index.

Persistencia de estado en Apify

El tercer punto no es un bug de código, sino un malentendido sobre cómo Apify gestiona los tests automatizados. La plataforma ejecuta diariamente cada Actor publicado con su entrada por defecto, esperando éxito, finalización en menos de 5 minutos y un dataset no vacío. Si dos de las últimas tres ejecuciones fallan, el Actor se marca como "Under maintenance" y desaparece de la búsqueda de la tienda. Dos trampas comunes aquí: usar una consulta por defecto demasiado específica que devuelva cero resultados (lo cual cuenta como fallo aunque el código sea correcto) y añadir lógica de reintentos que supere el límite duro de 5 minutos.

Además, el autor señala que Actor.getValue() y Actor.setValue() operan sobre la tienda de clave-valor actual, que se resetea en cada ejecución. Para persistir datos como un jar de cookies entre ejecuciones separadas, es necesario abrir una tienda nombrada explícitamente con Actor.openKeyValueStore(name=...). Un detalle obvio en retrospectiva, pero que costó un día de depuración al confiar en los nombres de los métodos.