Confirma si existen dos órdenes distintas en el bróker y compara los eventos de alerta, las entregas y las solicitudes del servicio receptor que las precedieron. Filas de pantalla similares pueden representar etapas distintas o ejecuciones parciales. Evita reenviar, cancelar o cambiar los ajustes de posiciones duplicadas antes de establecer el estado real de la cuenta y la cronología de los eventos.
Orientación educativa sobre software. Operar conlleva riesgos. Lea los avisos financieros y de información.
Construye la cronología de eventos
| Capa | Evidencia |
|---|---|
| Script/alerta | Origen del evento, identidad de la alerta y hora de activación |
| Entrega | Cada intento de webhook y su respuesta |
| Receptor | Cada mensaje aceptado o rechazado y la solicitud generada |
| Bróker | Identidades de orden distintas, estado y ejecuciones |
| Cuenta | Posición actual y órdenes activas restantes |
Conserva los identificadores privados en la investigación de la cuenta; ocúltalos en los ejemplos públicos. Usa Order History y Fill History para distinguir los eventos de órdenes de los registros de ejecución.
Revisa las posibles causas sin dar ninguna por supuesta
- Determina si dos alertas activas por separado transmiten la misma operación prevista.
- Comprueba si tanto el flujo de ejecución de órdenes de la estrategia como el de
alert()se activaron realmente con mensajes de operación. - Comprueba el enrutamiento a varias cuentas y el escalado de cantidades; las solicitudes intencionadas por cuenta no son duplicados automáticamente.
- Compara los intentos de transporte con los registros del receptor y del bróker antes de atribuirlo a un reenvío.
- Separa las ejecuciones parciales o las actualizaciones de estado de una misma orden de dos órdenes distintas.
La documentación de alertas de TradingView explica los flujos de eventos independientes. Seleccionar ambos no duplica necesariamente cada operación; importan el script real y los mensajes.
TradingView puede reenviar ciertas entregas
La regla oficial de reenvío abarca las respuestas HTTP 500–599 excepto 504, con reenvíos tras cinco segundos y hasta cuatro envíos por activación. Es un comportamiento de transporte. No demuestra que existan órdenes duplicadas en el bróker en un incidente concreto ni certifica la deduplicación del receptor.
Un interruptor de apilamiento de posiciones no es una garantía de entrega
La referencia JSON de PickMyTrade incluye una opción de posiciones duplicadas. No conviertas esa opción en una garantía universal de identificador de evento o de idempotencia, ni supongas que desactivarla resuelve todas las entradas duplicadas. Usa las instrucciones actuales del generador e investiga las solicitudes reales.
Para esta guía no se provocó ningún incidente de duplicación ni se cambió ningún ajuste de cuenta. Ofrece un método de conciliación, no una causa raíz certificada para una cuenta concreta.
Qué entregar al soporte
Proporciona la cronología con los datos ocultos, las marcas de tiempo y zonas horarias relevantes, los tipos de evento, el contexto de conexión y cuenta, y los resultados registrados. Pídele que explique cómo gestiona realmente el receptor la entrega repetida en la versión o el flujo de trabajo afectados. No canceles a ciegas una de las dos filas de un ejemplo de un artículo.
Preguntas frecuentes
¿Demuestran dos ejecuciones que hay dos órdenes duplicadas?
No. Una misma orden puede tener ejecuciones parciales. Concilia la identidad de la orden, la cantidad y el estado.
¿Reintenta TradingView todos los errores?
No. La regla de reenvío documentada tiene condiciones de respuesta específicas. No la amplíes a cualquier tiempo de espera o fallo.
¿Demuestra la desactivación de posiciones duplicadas la idempotencia?
No. El comportamiento de apilamiento de posiciones y el tratamiento de una misma entrega recibida dos veces son cuestiones distintas.
¿Debo reenviar cuando se desconoce el resultado en el bróker?
Primero concilia el registro de la cuenta y de las órdenes, o usa el proceso de investigación admitido por el proveedor.