Kraken: cuatro correcciones de fiabilidad en los clientes WebSocket y Futures REST

Cuatro defectos independientes de Kraken se corrigieron en 2026.9, y ninguno de ellos era del tipo que se detecta leyendo el código una sola vez. Cada uno solo se manifiesta bajo una condición concreta: el endpoint incorrecto en el momento de conectar, un cuerpo de petición que nunca sale de la máquina, una reconexión que ocurre unos cientos de milisegundos demasiado pronto. Los cuatro están corregidos, y los cuatro merecen entenderse, porque en cada caso el modo de fallo parece ser otra cosa completamente distinta.

El cliente spot hablaba v1 con un endpoint v2

TsgcWSAPI_Kraken construye y analiza el esquema v1: event, pair, subscription, subscriptionStatus, systemStatus. Ese esquema existe por una razón: es contra lo que está escrita cada llamada de suscripción y cada manejador de eventos de este componente. El endpoint al que se conectaba, sin embargo, apuntaba por defecto al WebSocket v2 de Kraken, que habla un esquema completamente distinto: method, params, channel, type. La conexión se abría sin error. Simplemente nunca producía ni un solo evento de confirmación de suscripción o de estado, porque el servidor respondía con una forma que el cliente nunca analiza.

Kraken.Version ahora tiene por defecto 1, y el componente elige el endpoint v1 correspondiente:

uses
  sgcWebSocket, sgcWebSocket_APIs;

var
  oKraken: TsgcWSAPI_Kraken;
begin
  oKraken := TsgcWSAPI_Kraken.Create(nil);
  oKraken.Client := oClient;
  // Version defaults to 1, matching the event/pair/subscription
  // schema this component already builds and parses.
  oKraken.Kraken.Version := 1;
  oClient.Active := True;
  oKraken.SubscribeTicker('XBT/USD');
end;

Si su aplicación de algún modo dependía del valor por defecto antiguo, silenciosamente incorrecto, eso significa que en realidad nunca estaba recibiendo eventos v1 tampoco, así que no hay nada que funcione hoy que deba preservarse. Establecer Kraken.Version := 2 explícitamente sigue conectando al endpoint v2, con RawMessages habilitado y el payload gestionado en OnKrakenData u OnMessage, para quien esté construyendo contra ese esquema a propósito.

Órdenes de Futures enviadas como GET, cuerpo descartado

Este es más silencioso y más grave. Cada petición privada del cliente REST de Kraken Futures, enviar una orden, editarla, cancelarla, una transferencia, un retiro, salía como una petición HTTP GET. El cuerpo de la petición firmada se construía correctamente, se calculaba, se formateaba, quedaba listo para enviarse, y después se descartaba, porque una petición GET no tiene cuerpo donde ponerlo. Kraken recibía un GET sin parámetros y lo rechazaba o lo ignoraba. Ninguna de estas llamadas funcionaba.

uses
  sgcHTTP_API_Kraken;

var
  oKraken: TsgcHTTP_API_Kraken_Futures_Rest;
  oOrder: TsgcHTTPKrakenFuturesOrder;
begin
  oKraken := TsgcHTTP_API_Kraken_Futures_Rest.Create(nil);
  oKraken.KrakenOptions.ApiKey := 'your_api_key';
  oKraken.KrakenOptions.ApiSecret := 'your_api_secret';

  oOrder := TsgcHTTPKrakenFuturesOrder.Create;
  try
    oOrder.OrderType := kotfLMT;
    oOrder.Symbol := 'PF_XBTUSD';
    oOrder.Side := kosfBuy;
    oOrder.Size := 1;
    oOrder.LimitPrice := 30000;
    // SendOrder now posts through DoHTTP_POST_PRIVATE, body included.
    ShowMessage(oKraken.SendOrder(oOrder));
  finally
    oOrder.Free;
  end;
end;

SendOrder, EditOrderByOrderId, EditOrderByCliOrderId, CancelOrderByOrderId, CancelOrderByCliOrderId, Transfer y WithdrawalToSpotWallet ahora se dirigen todas a través de la ruta POST privada, con el cuerpo firmado realmente adjunto a la petición.

Suscripciones privadas perdidas al reconectar

El WatchDog reconecta, el registro muestra una reconexión limpia, y a partir de ahí sus canales de órdenes, saldo y ejecuciones simplemente desaparecen. Nada da error. Nada se registra en el log. La reconexión parecía completamente exitosa, porque la conexión en sí sí tenía éxito; eran únicamente las suscripciones privadas emitidas antes de la desconexión las que nunca se reproducían después. Esto afectaba tanto a Kraken spot como a Kraken Futures por igual, junto con otros varios clientes de exchanges corregidos en la misma revisión. Ahora forma parte de la reproducción estándar de resuscripción, la misma ruta que ya restaura sus suscripciones de datos de mercado públicos tras una reconexión.

Futures resuscribía antes de que la sesión estuviera autenticada

Un defecto estrechamente relacionado, específico de Kraken Futures: tras una reconexión, la reproducción de las suscripciones activas podía ejecutarse antes de que el proceso de autenticación hubiera terminado realmente. Las peticiones de suscripción salían en una sesión que Kraken aún no había autenticado, así que las privadas eran rechazadas, de nuevo sin nada en el cliente que indicara el motivo. La reproducción ahora espera a que termine la autenticación antes de resuscribir.

Actualización

Las cuatro correcciones son directas, no hay ninguna API que migrar. El único cambio de comportamiento a tener en cuenta es el giro del valor por defecto de Kraken.Version, del valor anterior, efectivamente no funcional, a 1; si su código ya establece Version := 2 explícitamente, nada cambia para usted.

¿Preguntas, comentarios o ayuda con la migración? Póngase en contacto — recibirá una respuesta de las personas que escribieron el código.