Dinoer

Lo que un agente no puede adivinar

«El clic ha funcionado» es verdad y no dice casi nada. Dónde se separan una ejecución que funcionó y un resultado que se produjo, y las señales que devuelve Dinoer para distinguirlos.

Un agente que maneja el núcleo de navegación sabe una cosa con certeza: si su propia instrucción se ejecutó. Hizo clic, el clic ocurrió, succes: true.

Eso es compatible con un servidor que no recibió nada, un formulario rechazado, una sesión caducada o una página que era la equivocada desde el principio.

Tres formas en que un éxito no es un resultado

El navegador se negó a enviar el formulario. Un campo required estaba vacío y la validación HTML5 bloqueó el envío. El clic ocurrió; no se envió nada.

El clic era sintético. Un .click() de JavaScript sobre un botón de envío dispara el evento de clic sin garantizar que el formulario se envíe.

La página no era la esperada. Una redirección llevó a otro sitio del que suponía el escenario, y el clic cayó en una página que nadie quería tocar.

En los tres casos, la propia salida del agente no basta para que lo sepa. El formulario que nunca se envía →

El tiempo no se ve

Una página puede estar cargada del todo y no estar lista todavía.

Tras enviar un formulario de inicio de sesión, la red se calma y la navegación termina. El agente concluye que la sesión existe, va a una página protegida y vuelve a caer en la página de inicio de sesión.

Muchas aplicaciones regeneran el identificador de sesión justo después de la autenticación: el navegador ha terminado, el servidor no, y nada en la página distingue «en calma porque ha terminado» de «en calma entre dos estados». No hay ninguna señal que esperar; es el único caso en que una pausa fija es la herramienta adecuada:

{"type": "cliquer", "selecteur": "button[type=\"submit\"]"},
{"type": "pause", "ms": 2000},
{"type": "naviguer", "url": "https://target.local/protected"}

Qué hace Dinoer al respecto

No puede cerrar la brecha: ninguna herramienta puede hacerlo desde dentro del navegador. Devuelve señales que hacen visible una suposición equivocada.

Dónde está. boussole contiene la URL tras las redirecciones, el título de la página y el último estado HTTP.

La deriva de sesión. Tras --reprendre-session, aparece boussole.session_derive cuando la página a la que llegó difiere de aquella en la que se guardó la sesión. dernier_code_http separa entonces dos fallos que se parecen: una caducidad real redirige (302), un error de la aplicación devuelve 500 y la misma página de inicio de sesión.

La alternativa usada. repli_js_utilise solo aparece cuando se ejecutó de verdad un clic alternativo en JavaScript.

Ninguna de estas señales es una garantía. Cada una convierte una suposición equivocada y silenciosa en algo que usted puede leer.

El hábito que se desprende

Lea la respuesta, no el veredicto. succes: true es el campo menos informativo de la salida: dice que la instrucción se ejecutó. Si el trabajo se hizo, lo dice todo lo demás: dónde está, qué respondió el servidor, si hubo que forzar algo.

La cadena de investigación sigue la misma regla: campagne.py lee el estado de cada página que obtiene (visitee, refusee, insuffisante_legere y otros) y solo conserva las páginas que pudo leer.

En resumen

  • Una ejecución que funcionó y un resultado que se produjo son dos afirmaciones distintas.
  • Una red en calma no significa un servidor listo.
  • Las señales existen (posición, estado HTTP, deriva de sesión, alternativa usada) y dicen más que el veredicto.