El día que un cBot se reinicia no debería inventarse una cuenta nueva. Debe mirar primero qué posiciones y órdenes pendientes siguen vivas, decidir cuáles son suyas y solo entonces volver a operar. Si no puede hacerlo, una orden duplicada no es un accidente raro: es una consecuencia previsible.
La prueba de reinicio de un cBot no trata de adivinar el mercado. Trata de demostrar que, tras una interrupción definida, el proceso vuelve a estar situado en la cuenta real y no en el recuerdo que tenía antes de pararse.
La cuenta manda; la memoria solo ayuda
La reconciliación consiste en comparar el estado que conserva el algoritmo con el estado que cTrader muestra ahora. Las posiciones y las órdenes pendientes son la referencia. Un registro local puede servir para recordar que una barra ya fue procesada o que existe un periodo de espera; no debe sustituir lo que hay realmente en la cuenta.
cTrader expone eventos Open, Modified y Closed para posiciones, también cuando la actividad la origina una acción manual. La documentación de operaciones de cBot explica ese modelo. Esos eventos mantienen actualizado al cBot mientras está activo. Al arrancar de nuevo, la comprobación de las colecciones actuales sigue siendo necesaria.
| Dato que necesita el cBot | De dónde debe salir al reiniciar | Error que evita |
|---|---|---|
| Posiciones y órdenes pendientes | La cuenta actual de cTrader | Abrir de nuevo una exposición ya existente |
| Barra o señal ya atendida | Un registro de estrategia pequeño y definido | Ejecutar dos veces la misma señal |
| P&L, volumen y riesgo vigente | Un cálculo de nuevo con datos de cuenta | Tomar decisiones con valores obsoletos |
Antes de detenerlo, define qué puede hacer al volver
Una recuperación prudente tiene un contrato sencillo. Tras OnStart(), el cBot lee posiciones y órdenes pendientes, filtra las que identifica como propias, recupera el guard de una operación por barra o el cooldown que necesite, se suscribe a los eventos y espera a completar esa revisión antes de enviar una orden.
El detalle de las etiquetas depende del diseño. Lo importante es comprobar que una etiqueta, símbolo e identificador de instancia no confunden una operación manual, otro cBot o una segunda instancia. Una etiqueta no es un adorno: delimita propiedad.
Si el sistema conserva datos, limita el contenido y versiona el formato. La guía de almacenamiento local de cTrader indica que el alcance por defecto es el de instancia, que los datos se guardan automáticamente cada minuto y al detener la instancia, y que Flush() permite guardar sin esperar. Eso justifica hacer un checkpoint después de una transición terminada. No demuestra, por sí solo, que una orden llegó a la cuenta.
Cinco escenas que un reinicio debe superar
No basta con apagar un cBot sin posiciones y encenderlo de nuevo. Ahí no hay casi nada que reconciliar. Prepara estados donde la respuesta correcta pueda comprobarse en el historial.
Posición abierta gestionada por el cBot
Detén el proceso con una posición identificada como propia. Al volver, debe encontrarla y no añadir una segunda entrada por la misma exposición prevista. Conserva los IDs, etiquetas, volumen y hora antes de parar, al iniciar y tras el primer ciclo de decisión.
Orden pendiente viva
Repite la prueba con una orden pendiente. El contrato debe decir si la conserva, cancela o modifica; lo que no vale es que cree otra igual por no haber visto la primera.
Reinicio a ambos lados de la señal
Haz una prueba justo antes y otra justo después de que se cumpla la condición de entrada. Son dos estados distintos. La comprobación más útil es binaria: el reinicio genera zero órdenes adicionales para la configuración ya procesada, o no las genera. El historial de cuenta debe poder resolverlo sin interpretación.
Cambios fuera del cBot
Modifica una posición manualmente, o simula el efecto con una prueba aislada. Decide por adelantado si el cBot debe dejar de gestionarla, adoptar el cambio o registrar una discrepancia. Sobrescribir sin aviso un stop loss manual no es recuperación; es falta de propiedad definida.
Cuenta plana
Por último, reinicia sin posiciones ni órdenes. Confirma que el cBot no repite una acción anterior y que solo actúa si la señal actual cumple las reglas otra vez.
El backtest no reproduce la persistencia real
El almacenamiento local sirve para pasar datos entre paradas e inicios, pero no se comporta igual en todos los contextos. cTrader documenta que durante backtesting y optimización funciona únicamente en memoria. Por eso un backtest limpio puede validar una secuencia histórica de órdenes y, aun así, dejar sin probar qué ocurre con el estado persistente en una ejecución real.
El alcance elegido también importa. cTrader documenta ámbitos de instancia, tipo y dispositivo. Un ámbito más amplio requiere claves que separen de forma deliberada las instancias. Compartir almacenamiento sin esa separación convierte una comodidad en una fuente de colisiones.
La ejecución en Cloud merece su propia prueba. Los requisitos de cTrader Cloud señalan que, al detener o borrar una instancia, se liberan sus recursos y se eliminan los archivos que creó cuando se reinicia o se borra. No extrapoles el resultado de un equipo de escritorio: valida el ciclo de vida exacto del despliegue que usas.
Cuando hay discrepancia, no la tapes con una orden
Si el checkpoint y la cuenta no coinciden, la recuperación debe reducir incertidumbre. A veces significa escribir el motivo en el log y esperar a la siguiente señal definida. Cerrar, sustituir o alterar una orden tiene consecuencias de trading; no debería colarse dentro de un manejador de reinicio.
Esa separación hace más verificable la metodología: las hipótesis de ejecución, las restricciones de cuenta y las validaciones quedan a la vista. También importa en una cuenta de fondeo, donde una posición extra altera el camino de equity que miden las reglas de pérdida.
realbacktesting es un estudio de software de trading para cTrader centrado en pruebas que puedes inspeccionar. Un log de recuperación no convierte una estrategia en rentable ni garantiza que no fallen la red o la plataforma. Sí puede demostrar si la respuesta del cBot a una interrupción concreta estuvo bajo control.
Preguntas frecuentes
¿Un backtest de cTrader prueba que el cBot se recupera tras reiniciar?
No. Puede probar la lógica histórica de órdenes, pero cTrader indica que el almacenamiento local usa memoria durante backtesting y optimización. La ejecución en tiempo real necesita una prueba aparte.
¿Hay que guardar todos los detalles de la cuenta?
No. Las posiciones y órdenes pendientes actuales se deben reconciliar desde cTrader al arrancar. Conserva solo la memoria mínima para no repetir ni saltarte una acción definida.
¿Qué evidencia debo guardar de la prueba?
Guarda el log con hora, los IDs de posiciones y órdenes, etiquetas, volúmenes y la primera decisión tras arrancar. Una captura enseña el resultado; el registro permite comprobar por qué no hubo una duplicación.
¿El almacenamiento local sobrevive siempre a un reinicio en Cloud?
No lo des por hecho. Los requisitos de Cloud de cTrader indican que los recursos de una instancia detenida o eliminada se liberan; valida el comportamiento del ciclo de vida y del almacenamiento que utiliza tu cBot.
La idea que no conviene olvidar
Si un cBot no puede explicar qué órdenes ya existen después de reiniciarse, todavía no tiene derecho a colocar la siguiente.