Ayer, en el historial @Dusk , constaba que las estadísticas archive-only tenían valores reales y que había registros tanto del total como del número de cuentas; valía la pena rastrearlo con un script de recuperación. Hoy hay que decidir qué ruta seguir. Los registros antiguos indican una ruta sin prefijo; las pruebas muestran que no funciona y la documentación indica otra. Las tres capas no coinciden. Primero, comprobar la ruta; no confiar en la memoria.
En la misma ventana horaria, hoy de 13:00:54 a 13:01:58, UTC+8. En la red principal y en la red de pruebas, con dos métodos de solicitud, se hicieron 11 solicitudes de solo lectura a dos rutas sin prefijo y tres variantes. Los cuerpos de las respuestas fueron idénticos: en todos los casos, no se encontró la ruta; el código de estado fue 404.
/on/node/info y otro endpoint de referencia devolvieron 200, así que se descarta un fallo de todo el sitio. Hay 404 y 200 a la vez: lo que falla es la ruta, no la red. En las dos redes, con dos métodos y tres variantes, la única variable que se cambió fue la ruta. Compara bajo las mismas condiciones y en la misma ventana; luego saca conclusiones.
Ahora, la documentación. La documentación y la implementación son dos variables distintas: hay que comprobarlas por separado, sin que una hable en nombre de la otra. En la instantánea de la documentación, la ruta lleva el prefijo /on/, como /on/stats/tx_count. La capa de implementación devuelve 404; la documentación señala /on/. Estos dos hechos no se contradicen. La prueba demuestra que la ruta sin prefijo no funciona; la documentación indica otra ruta, la oficial. No hablan de lo mismo, así que ambas cosas pueden ser ciertas al mismo tiempo. Lo que realmente contradice lo observado hoy es la ruta sin prefijo de los registros antiguos: no supera las pruebas ni coincide con la documentación.
La ruta sin prefijo devolvió 404 en las pruebas; hoy queda descartada. La ruta que debe usar el script de recuperación es la que indica la documentación. Si se copia tal cual la ruta sin prefijo, el script se detendrá en la primera solicitud y no recuperará ninguno de esos valores reales: se quedará sin nada. Recuérdalo: los scripts de recuperación y estadísticas deben usar POST /on/stats/*, según la documentación; no se debe elegir la ruta de memoria.
Hoy no se volvió a comprobar la ruta de la documentación; se agotó el presupuesto de sondeo de esta ventana. Hoy solo se han demostrado dos cosas: la ruta sin prefijo no funciona y la documentación señala /on/. No se ha demostrado que esa ruta tenga datos hoy. Que no se haya comprobado no significa que no los haya; por hoy, las conclusiones se limitan a esos dos puntos. No extrapolar más.
Tras cambiar a la ruta de la documentación para la interfaz de estadísticas de la cadena $DUSK , primero hay que revisar la respuesta y después confiar en los números. Antes que los números, la ruta. #dusk
En la misma ventana horaria, hoy de 13:00:54 a 13:01:58, UTC+8. En la red principal y en la red de pruebas, con dos métodos de solicitud, se hicieron 11 solicitudes de solo lectura a dos rutas sin prefijo y tres variantes. Los cuerpos de las respuestas fueron idénticos: en todos los casos, no se encontró la ruta; el código de estado fue 404.
/on/node/info y otro endpoint de referencia devolvieron 200, así que se descarta un fallo de todo el sitio. Hay 404 y 200 a la vez: lo que falla es la ruta, no la red. En las dos redes, con dos métodos y tres variantes, la única variable que se cambió fue la ruta. Compara bajo las mismas condiciones y en la misma ventana; luego saca conclusiones.
Ahora, la documentación. La documentación y la implementación son dos variables distintas: hay que comprobarlas por separado, sin que una hable en nombre de la otra. En la instantánea de la documentación, la ruta lleva el prefijo /on/, como /on/stats/tx_count. La capa de implementación devuelve 404; la documentación señala /on/. Estos dos hechos no se contradicen. La prueba demuestra que la ruta sin prefijo no funciona; la documentación indica otra ruta, la oficial. No hablan de lo mismo, así que ambas cosas pueden ser ciertas al mismo tiempo. Lo que realmente contradice lo observado hoy es la ruta sin prefijo de los registros antiguos: no supera las pruebas ni coincide con la documentación.
La ruta sin prefijo devolvió 404 en las pruebas; hoy queda descartada. La ruta que debe usar el script de recuperación es la que indica la documentación. Si se copia tal cual la ruta sin prefijo, el script se detendrá en la primera solicitud y no recuperará ninguno de esos valores reales: se quedará sin nada. Recuérdalo: los scripts de recuperación y estadísticas deben usar POST /on/stats/*, según la documentación; no se debe elegir la ruta de memoria.
Hoy no se volvió a comprobar la ruta de la documentación; se agotó el presupuesto de sondeo de esta ventana. Hoy solo se han demostrado dos cosas: la ruta sin prefijo no funciona y la documentación señala /on/. No se ha demostrado que esa ruta tenga datos hoy. Que no se haya comprobado no significa que no los haya; por hoy, las conclusiones se limitan a esos dos puntos. No extrapolar más.
Tras cambiar a la ruta de la documentación para la interfaz de estadísticas de la cadena $DUSK , primero hay que revisar la respuesta y después confiar en los números. Antes que los números, la ruta. #dusk