La sesión no se mantiene entre dos llamadas

El síntoma. Usted reparte un trabajo en dos llamadas. La primera se autentica y guarda la sesión; la segunda la reutiliza. O la segunda llamada vuelve a caer en la página de inicio de sesión, o — y esto es peor — devuelve succes: true en un segundo más o menos y no cambia nada en el destino.

Lo que ocurre realmente

Una sesión guardada es un storage_state de Playwright: cookies y localStorage, nada más. Hay dos cosas que no están ahí, y son justo las que le hacen caer.

El estado del DOM no está. Una casilla que marcó, un <select> que ajustó, un diálogo que abrió — todo desaparece al reanudar. La página vuelve limpia. Sus acciones numeradas se ejecutan entonces sobre una página nueva, dan con el elemento que ahora lleva ese número, e informan de éxito. Ningún error, porque desde el punto de vista de Diwall nada fue mal: pulsó el elemento 7, y el elemento 7 existía.

La sesión del lado del servidor tampoco está. Muchas aplicaciones llaman a algo equivalente a session_regenerate_id() justo después del inicio de sesión. La cookie que usted guardó es la de antes de la regeneración. La instantánea del lado del cliente es perfectamente válida y perfectamente inútil.

La regla

No reparta nunca un trabajo con estado. Iniciar sesión, actuar y confirmar en una sola llamada, aunque eso suponga volver a iniciar sesión.

Medido en un destino real: la versión en una sola llamada tardó 7,5 segundos y funcionó; la versión repartida tardó 1,1 segundos y no hizo nada, sin avisar. La rápida es la que falló.

Una sola llamada admite una lista de acciones — para eso existe la lista:

diwall-shot --url https://target.local/login --som --guide-version 1.3 \
  --actions '[
    {"type": "remplir_som", "id": 4, "valeur": "depuis_secrets", "secret_cle": "username"},
    {"type": "remplir_som", "id": 5, "valeur": "depuis_secrets", "secret_cle": "password"},
    {"type": "cliquer_som", "id": 7},
    {"type": "attendre_selecteur_present", "selecteur": ".user-menu"},
    {"type": "cliquer_som", "id": 12}
  ]'

Un arranque de navegador, una captura final. La versión repartida cuesta por llamada un arranque de Playwright, una recarga del almacenamiento y un nuevo cálculo completo de Set-of-Mark — es más lenta en cada paso y pierde su estado entre uno y otro.

Cuándo la persistencia es la herramienta adecuada

La persistencia de sesión no es una trampa, es una herramienta de uso limitado: leer varias páginas autenticadas que no dependen unas de otras. Un panel de control, luego una página de ajustes, luego un informe — cada una independiente.

# Autenticarse una vez
diwall-shot --url https://target.local/login --som --guide-version 1.3 \
  --actions login.json --sauver-session ~/session.json

# Leer tantas páginas independientes como quiera
diwall-shot --url https://target.local/dashboard --som --guide-version 1.3 \
  --reprendre-session ~/session.json

Desde la 1.11.1, el archivo de sesión ya no se borra al final de la ejecución, así que las llamadas encadenadas son seguras. Vuelva a poner --sauver-session solo para refrescar a propósito el estado guardado.

La línea que conviene mantener: la persistencia lleva quién es usted, no lo que estaba haciendo.

Leer la respuesta, no solo el veredicto

Cada llamada tras --reprendre-session le dice si la sesión se ha mantenido:

"boussole": {
  "session_derive": true,
  "url_courante": "https://target.local/login",
  "dernier_code_http": 302
}

session_derive: true significa que ya no está donde creía estar. Vuelva a ejecutar el inicio de sesión completo, sin --reprendre-session.

Lea después dernier_code_http, porque dos fallos muy distintos se ven idénticos. Una sesión realmente caducada y un error de aplicación oculto tras display_errors=0 le dejan en ambos casos en la página de inicio de sesión con session_derive: true. Un 302 o un 200 señala una caducidad real: vuelva a entrar. Un 500 o un 4xx significa que la aplicación falló y que su sesión nunca fue el problema; volver a entrar solo le hará perder tiempo.

Un matiz: en una ejecución con varias acciones naviguer, este campo solo refleja la última navegación, que no es necesariamente la que explica la deriva.

En resumen

• Con estado — iniciar sesión, actuar, confirmar: una llamada, una lista de acciones.
• Sin estado — leer páginas autenticadas independientes: la persistencia sirve.
• Tras cada reanudación: mire session_derive, luego dernier_code_http.
• Un succes: true rápido en un trabajo que esperaba lento es un aviso, no un resultado.