Ciclo de vida del resultado
Un modelo de datos para los resultados de registro en Telegram y los intentos de actualización
Almacene los campos de la respuesta de registro en Telegram, distinga los resultados completados de los errores de la API y conserve una marca de tiempo local de la respuesta.
Por qué un solo booleano no basta
Un resultado de registro en Telegram es una observación con marca de tiempo producida por una verificación completada, no una verdad permanente asociada a un número de teléfono.
Un campo como telegram_valid pierde un contexto esencial. No indica qué número normalizado se verificó, cuándo se ejecutó la verificación, si el false fue una decisión completada ni si la solicitud falló en realidad. La base de datos debe conservar esas distinciones para que una aplicación pueda mostrar y actualizar el resultado con honestidad.
TG Validator devuelve una decisión completada de forma síncrona, lo que significa que la observación puede escribirse en cuanto llega la respuesta HTTP. Los campos devueltos deben almacenarse tal cual, sin inventar otro conjunto de estados de producto.
Separe el sujeto de sus observaciones
Utilice un registro interno estable por teléfono y asóciele varias observaciones de verificación. Así se evita reescribir el historial y resulta fácil entender una actualización posterior.
| Registro | Campos sugeridos | Finalidad |
|---|---|---|
| Teléfono de origen | phone_id, source_phone, source_system |
Conserva el registro empresarial original |
| Teléfono normalizado | phone_id, e164_phone, normalized_at |
Registra el valor canónico utilizado en las verificaciones |
| Observación de verificación | phone_id, service_type, registered, received_at |
Almacena un resultado síncrono |
Si la normalización cambia porque se corrigió el contexto de país original, cree el registro canónico o genere una nueva versión de él. No asocie de forma silenciosa un resultado antiguo de Telegram a un número de teléfono reinterpretado.
Utilice exactamente las estructuras de respuesta documentadas
| Estructura devuelta | Valor de registered |
Significado |
|---|---|---|
code=0, data.registered=true |
true | La verificación completada indicó registrado |
code=0, data.registered=false |
false | La verificación completada indicó no registrado |
code de la API distinto de cero |
Ausente | Sin decisión de registro; error de la API, no un resultado de registro |
La distinción es deliberada. Un código de la API distinto de cero significa que el servicio no tiene ninguna respuesta booleana que almacenar. Las entradas no válidas, los rechazos por concurrencia, el saldo insuficiente, el mantenimiento y los fallos internos no añaden más valores a data.registered.
Mantenga el estado actual y el último intento como dos vistas
Suelen ser útiles dos preguntas:
- ¿Cuál es la observación de registro completada más reciente?
- ¿Qué ocurrió en el intento de solicitud más reciente?
Pueden apuntar a filas distintas. Si un resultado true completado en T1 va seguido de un error de la API en T2, la observación completada más reciente sigue siendo true en T1, mientras que un registro de solicitudes independiente puede anotar el estado HTTP y el código de la API de T2. Así se evita que un operador confunda T1 con un resultado reciente o T2 con un false.
Cuando una llamada posterior se completa con false en T3, la vista del estado completado avanza a T3. Los registros de T1 y T2 siguen disponibles para auditoría y resolución de problemas.
Defina cuándo es necesaria una actualización
TG Validator proporciona una observación síncrona actual cuando se le llama, pero la política de vigencia corresponde a la aplicación integradora. Elija una antigüedad máxima aceptable según la decisión que se vaya a tomar y haga visible esa antigüedad en la interfaz.
Una política de actualización debe especificar:
- la antigüedad máxima aceptada para cada flujo de trabajo;
- si los operadores pueden utilizar un resultado completado más antiguo tras un error posterior de la API;
- qué respuestas de la API distintas de cero deben volver a enviarse más adelante;
- cómo condiciona la planificación el límite de concurrencia por usuario;
- si se conservan a largo plazo todos los intentos o solo las observaciones completadas.
No reintente un registered=false completado solo porque sea false. Reintente cuando necesite una observación más reciente o cuando el intento anterior no produjo ninguna decisión.
Una consulta precisa del estado actual
El estado de registro actual debe seleccionar la última observación en la que la respuesta exterior tuvo code=0 y devolver juntos su valor registered y su received_at local. Nunca devuelva el booleano sin su marca de tiempo.
El estado del último intento debe seleccionar la observación más reciente de cualquier estado. Si no está completada, la interfaz puede explicar que se intentó una verificación más reciente sin sustituir el último resultado de registro conocido.
El principio de diseño duradero
Añada observaciones, conserve sus marcas de tiempo y nunca convierta la incertidumbre operativa en un valor de registro en Telegram.
Este modelo se ajusta exactamente al producto. TG Validator responde de forma síncrona a una única pregunta de registro; no proporciona datos de identidad ni de perfil de cuenta. La aplicación del cliente aporta el registro estable, la política de conservación, el calendario de actualizaciones y la decisión de negocio en torno a cada observación.