¿Por qué recibo 403 en getTransactions pero no en getAccountState?

getAccountState lee el estado actual, que el nodo ligero siempre tiene. Un recorrido de transacciones va hacia atrás en el tiempo, y en cuanto supera la ventana de unos dos días del nodo ligero, el gateway lo enruta al nodo de archivo — que un plan sin archivo no puede usar. El texto del 403 nombra la razón: archive history is not included in this plan.

¿Cuál es la diferencia entre 651 y -503?

651 es ErrorCode::notready en el software del nodo: los datos existen en principio, pero este nodo no los tiene listos — un bloque aún no aplicado, o un lt fuera de su base de datos. -503 timeout es el plazo por consulta del propio nodo: tenía los datos pero no pudo componer la respuesta a tiempo.

Herramientas gratuitas

Códigos de error de liteserver TON

Cada liteServer.error que un gateway de TONNode o un nodo TON puede devolver, con lo que ha pasado y qué hacer. Las filas del gateway proceden de la documentación de LiteServers; las filas del nodo y del cliente enlazan a la línea de ton-blockchain/ton que las produce.

Buscar

18 de 18 códigos

Código	Mensaje	Qué ha pasado	Qué hacer
403	`archive history is not included in this plan` Gateway de TONNode	La consulta necesitaba un bloque que el nodo ligero ya no conserva, y el plan no incluye el alcance de archivo. El nodo ligero guarda unos dos días de historia al ritmo actual de bloques; el gateway enruta todo lo anterior al nodo de archivo y lo rechaza cuando el plan no lo incluye.	Añade archivo al plan, o consulta un bloque más reciente. No se puede reintentar: la misma consulta será rechazada de nuevo. Fuente: LiteServers docs, Chapter 4
403	`method not supported` Gateway de TONNode	El tipo de petición no está en la tabla de métodos del gateway, o se envió un lote más largo que un prefijo waitMasterchainSeqno más una consulta.	Usa un método documentado, sin prefijo o con el único prefijo admitido. Añadir archivo al plan no cambia esto. Fuente: LiteServers docs, Chapter 5
429	`too many requests` Gateway de TONNode	El límite de tasa del plan, un leaky bucket por clave de API denominado en unidades de coste: una lectura ordinaria cuesta 5, una página completa de getTransactions hasta 16, un bloque entero 50.	Espera y reintenta. Si es sostenido, regula el cliente al ritmo de recarga del plan o sube de plan. Fuente: LiteServers docs, Chapter 7
429	`too many concurrent requests for this key` Gateway de TONNode	Había más consultas abiertas a la vez desde esta clave de las que permite el plan: la mitad de su RPS, con un mínimo de 8 y un máximo de 128. Es un techo de trabajo en vuelo, no de tasa.	Acota tu fan-out: un Promise.all o un fan-out de goroutines sin límite choca con esto mucho antes que con el límite de tasa. Fuente: LiteServers docs, Chapter 7
429	`gateway is saturated, retry shortly` Gateway de TONNode	Se alcanzó el techo global de 256 consultas en vuelo entre todos los clientes. El backend está sufriendo, no tu plan.	Reintenta con backoff. Fuente: LiteServers docs, Chapter 7
502	`backend node timeout` Gateway de TONNode	El nodo no respondió dentro de la ventana del gateway: 7 s para el nodo ligero, 20 s para el archivo.	Reintenta una vez, de inmediato. Pon tu propio timeout de cliente por encima de esos valores, o convertirás un error real en un timeout local y perderás el diagnóstico. Fuente: LiteServers docs, Chapter 5
400	`canceled` Gateway de TONNode	Tu contexto o conexión desapareció a mitad de la consulta — normalmente tu propio timeout disparándose.	Del lado del cliente. Sube el timeout del cliente por encima de las ventanas de 7 s / 20 s del gateway. Fuente: LiteServers docs, Chapter 5
400	`non zero mode is not supported` Gateway de TONNode	Se llamó a getMasterchainInfoExt con un mode distinto de 0.	Envía mode: 0. Fuente: LiteServers docs, Chapter 5
-400	`unknown request type` Gateway de TONNode	El método pasa la comprobación del plan, pero el manejador de peticiones del gateway no lo implementa.	No hay nada que reintentar. Usa un método marcado como admitido en la referencia de métodos. Fuente: LiteServers docs, Chapter 5
500	`failed to …` Gateway de TONNode	El gateway no pudo componer una respuesta.	Reintenta. Si persiste, es cosa nuestra — escribe a soporte con el id de la clave y la hora. Fuente: LiteServers docs, Chapter 5
-400	`cannot locate transaction in block with specified logical time` Nodo TON	Un recorrido de getTransactions llegó a una transacción que el nodo no encuentra en el bloque esperado: casi siempre el recorrido sobrepasó la ventana de almacenamiento del nodo ligero.	En un plan con archivo, el gateway reintenta contra el archivo automáticamente. Sin archivo, esto es el límite de la historia — no es un fallo pasajero, no lo reintentes. Fuente: validator/impl/liteserver.cpp, LiteQuery::continue_getTransactions
-400	`… (other node text)` Nodo TON	El propio nodo falló la consulta y devolvió su texto; -400 es el código por defecto de un fallo de LiteQuery en el software del nodo. Textos comunes: invalid block id requested, shard not found, cannot unpack block header.	Lee el texto. Un id de bloque o shard erróneo es un error de la petición; los textos relacionados con el almacenamiento significan que el bloque está fuera de lo que este nodo conserva. Fuente: validator/impl/liteserver.hpp, LiteQuery::fatal_error default code
-503	`timeout` Nodo TON	El plazo por consulta del propio nodo venció mientras componía la respuesta: una prueba pesada, un disco lento o un bloque que hubo que traer del almacenamiento frío.	Reintenta una vez. Si una consulta concreta siempre vence, acótala — menos transacciones por página, un método más ligero. Fuente: validator/impl/liteserver.cpp, LiteQuery::alarm
651	`block … is not applied` Nodo TON	El nodo tiene el bloque pero aún no lo ha aplicado: todavía se está poniendo al día, o el seqno pedido va por delante de su estado. Cuando el seqno va por delante del nodo, el texto termina en "(last known masterchain block: N)".	Espera a que el nodo se ponga al día y reintenta. Si calculas los seqno tú mismo, no pidas bloques más nuevos de lo que informa getMasterchainInfo. Fuente: validator/manager.cpp, process_block_handle_for_litequery_error
651	`block … is not in db` Nodo TON	El nodo nunca recibió ese bloque: es más nuevo de lo que el nodo tiene, o más antiguo de lo que conserva.	Usa lookupBlock con la información actual de la masterchain para encontrar un bloque que exista; para bloques antiguos necesitas el alcance de archivo. Fuente: validator/manager.cpp, process_block_handle_for_litequery_error
651	`lt not in db` Nodo TON	lookupBlock por tiempo lógico pidió un lt que ningún índice de bloques de este nodo cubre: es más antiguo que el almacenamiento del nodo, o no existe ningún bloque con ese lt.	Consulta por seqno o por utime donde puedas; para un lt en el pasado, usa un plan con archivo. Fuente: validator/db/archive-manager.cpp, ArchiveManager::get_block_by_lt
652	`timeout for adnl query …` Cliente C++	La capa de consultas ADNL del cliente C++ (lite-client, tonlib) dejó de esperar una respuesta. Las bibliotecas de Python, JavaScript y Go lanzan sus propios errores de timeout en lugar de este código.	Sube el timeout del cliente por encima de las ventanas de 7 s / 20 s del gateway y revisa la ruta de red. Si el gateway respondió 502, esa es la causa real. Fuente: adnl/adnl-query.cpp, AdnlQuery::alarm
651	`not ready / conn not ready` Cliente C++	El cliente C++ envió una consulta antes de que su conexión con el liteserver terminara el handshake, o después de que la conexión se cayera.	Espera a que la conexión esté lista — las bibliotecas lo hacen por ti — y reconecta si una conexión inactiva se cierra, que es normal. Fuente: adnl/adnl-ext-client.cpp, AdnlExtClientImpl::send_query

651 = ErrorCode::notready, 652 = ErrorCode::timeout — common/errorcode.h

Se ejecuta en tu navegador. Nada de lo que pegas sale de esta página.

Cómo leer un error de liteserver

Un liteserver responde a cada consulta con el objeto pedido o con un liteServer.error que lleva un code entero y un message. El gateway de TONNode usa el mismo sobre para sus propios rechazos, así que tu biblioteca los muestra como muestra cualquier error del nodo: tonutils-go conserva el código en ton.LSError, pytoniq lanza LiteServerError con .code y .message, y ton-lite-client lanza un Error cuyo mensaje es solo el texto.

Los códigos vienen de dos sitios, y la tabla marca cuál:

Códigos del gateway — 400, 403, 429, 500, 502 — los produce el gateway de TONNode que se sitúa entre tu conexión ADNL y el nodo. Comprueba el método contra tu plan, aplica el límite de tasa y el techo de concurrencia, y enruta la consulta a un nodo ligero o a un nodo de archivo. Estas filas reproducen el capítulo 5 de la documentación de LiteServers.
Códigos del nodo vienen del software del nodo en ton-blockchain/ton. -400 es el código por defecto con el que se envía el texto de un fallo de LiteQuery, -503 timeout es el plazo por consulta del propio nodo, y 651 y 652 son ErrorCode::notready y ErrorCode::timeout de common/errorcode.h. Dos filas las produce el propio cliente C++ (lite-client, tonlib) y no el servidor; otros lenguajes lanzan sus propias excepciones en esas situaciones.

Los que más importan

403 archive history is not included in this plan. La única señal que importa cuando recorres la historia. La consulta necesitaba un bloque que el nodo ligero ya no conserva — el nodo ligero guarda unos dos días de historia al ritmo actual de bloques, un orden de magnitud más que una promesa — y el plan no tiene alcance de archivo. No se puede reintentar: añade archivo al plan o pide un bloque más reciente. El capítulo 4 explica dónde está el límite e incluye una sonda que lo mide para tu clave.

429, tres límites distintos. too many requests es el límite de tasa por clave, un leaky bucket denominado en unidades de coste: una lectura ordinaria cuesta 5, una página completa de getTransactions hasta 16, un bloque entero 50. too many concurrent requests for this key es el techo de consultas en vuelo — la mitad del RPS del plan, con un mínimo de 8 y un máximo de 128. gateway is saturated es el techo global de 256 consultas en vuelo entre todos los clientes. Los dos primeros significan que tu cliente necesita regular su ritmo; el último, que el backend está sufriendo, y la respuesta correcta es el backoff. El capítulo 7 tiene la tabla de costes y fragmentos de cliente con ritmo regulado.

502 backend node timeout. El nodo no respondió dentro de la ventana del gateway: 7 s para el nodo ligero, 20 s para el archivo. Pon tu propio timeout de cliente por encima de esos valores; uno más corto convierte un 502 real en un timeout local y pierde el diagnóstico.

651 y la familia "not in db". block … is not applied, block … is not in db y lt not in db llevan todos ErrorCode::notready. Significan que este nodo no tiene listo lo que pediste: todavía se está poniendo al día, el bloque va por delante de su estado, o el bloque o el tiempo lógico son más antiguos que su almacenamiento. Un bloque reciente aparecerá por sí solo; uno antiguo necesita archivo.

Qué reintentar

Reintenta 429 con backoff y 502 una vez, de inmediato. No reintentes 403 — ninguna variante se vuelve cierta en un segundo intento. Tampoco reintentes -400 de un recorrido de transacciones; es un límite, no un fallo pasajero. Para 651, reintenta tras un momento un bloque más nuevo que el estado del nodo, y deja de reintentar uno más antiguo que su almacenamiento.

Errores del stream de mempool

El stream de mempool es un protocolo distinto con su propia lista de errores — mensajes JSON error y códigos de cierre de WebSocket como 4401 y 4429 — y no está cubierto por esta tabla.

Preguntas frecuentes

¿Qué errores debo reintentar?: Reintenta 429 con backoff y 502 una vez, de inmediato. No reintentes 403 — ninguna de sus variantes se vuelve cierta en un segundo intento. Tampoco reintentes -400 de un recorrido de transacciones; es un límite, no un fallo pasajero. 651 significa que el nodo va atrasado o que el bloque está fuera de su almacenamiento: espera y reintenta para un bloque reciente, usa archivo para uno antiguo.
¿Por qué recibo 403 en getTransactions pero no en getAccountState?: getAccountState lee el estado actual, que el nodo ligero siempre tiene. Un recorrido de transacciones va hacia atrás en el tiempo, y en cuanto supera la ventana de unos dos días del nodo ligero, el gateway lo enruta al nodo de archivo — que un plan sin archivo no puede usar. El texto del 403 nombra la razón: archive history is not included in this plan.
¿Cuál es la diferencia entre 651 y -503?: 651 es ErrorCode::notready en el software del nodo: los datos existen en principio, pero este nodo no los tiene listos — un bloque aún no aplicado, o un lt fuera de su base de datos. -503 timeout es el plazo por consulta del propio nodo: tenía los datos pero no pudo componer la respuesta a tiempo.
¿Por qué mi biblioteca muestra un error distinto al de esta tabla?: Las bibliotecas envuelven el liteServer.error de formas distintas. tonutils-go conserva el código en ton.LSError, pytoniq lanza LiteServerError con code y message, y ton-lite-client lanza un Error que solo lleva el texto. Compara por el texto cuando el código no esté disponible.

Acceso privado a liteserverPlanes Litenode y Archive: consulta la cadena directamente con tu propia clave.Documentación de LiteServersTodos los métodos, límites de tasa, enrutamiento al archivo y el capítulo completo de errores.

Más herramientas

Conversor y validador de direcciones TONRaw ↔ EQ ↔ UQ, mainnet y testnet, comprobación de checksum, modo por lotes.Conversor de nanoton ↔ GRAM (TON) y unidades de jettonsGRAM ↔ nanoton con 9 decimales y cantidades de jettons ↔ unidades raw con cualquier número de decimales.Hash de mensaje TON a partir de un BoCcell_hash, norm_hash TEP-467 y sha256 de cualquier BoC de mensaje, en hex y base64.