Algunos errores fallan siempre. Otros fallan según un horario. El defecto de firma de Huobi y HTX corregido en la versión 2026.9 era del segundo tipo, y eso lo hacía mucho más difícil de identificar: en un host que se ejecutaba fuera de UTC, las solicitudes privadas fallaban durante parte de cada día y funcionaban durante el resto, lo cual parece exactamente un problema de autenticación intermitente hasta que alguien nota que el patrón coincide con el reloj.
Una marca de tiempo construida a partir de dos relojes distintos
Tanto Huobi como HTX exigen que la solicitud firmada incluya una marca de tiempo en UTC, con el formato yyyy-MM-ddTHH:mm:ss. La rutina de firma en TsgcWS_API_Huobi_Base, compartida por TsgcWSAPI_Huobi y TsgcWSAPI_HTX, construía esa marca de tiempo a partir de dos fuentes distintas: la parte de la fecha provenía del reloj local del sistema, y la parte de la hora provenía de UTC. Durante la mayor parte del día, en la mayoría de las máquinas, la fecha local y la fecha UTC coinciden, así que nada parecía estar mal. Cerca de la medianoche UTC, en cualquier host cuyo desfase de zona horaria local lo situara al otro lado de ese límite, la fecha y la hora dejaban de coincidir entre sí, la firma que Huobi calculaba por su cuenta no coincidía, y la solicitud era rechazada.
La corrección toma tanto la fecha como la hora del mismo valor UTC:
uses
sgcBase_Helpers;
var
vUTC: TDateTime;
vTimeStamp: string;
begin
vUTC := sgcGetDateTimeAsUTC;
vTimeStamp := FormatDateTime('yyyy-mm-dd', vUTC) + 'T' +
FormatDateTime('hh:nn:ss', vUTC);
end;No hay nada que configurar. TsgcWSAPI_Huobi y TsgcWSAPI_HTX llaman ambos a esta misma rutina de firma, así que ambos quedan corregidos a la vez:
uses
sgcWebSocket, sgcWebSocket_APIs;
var
oHuobi: TsgcWSAPI_Huobi;
begin
oHuobi := TsgcWSAPI_Huobi.Create(nil);
oHuobi.Client := oClient;
oHuobi.Huobi.ApiKey := 'your_api_key';
oHuobi.Huobi.ApiSecret := 'your_api_secret';
oClient.Active := True;
// Authentication now signs with a timestamp taken entirely from UTC.
oHuobi.SubscribeOrderUpdates('btcusdt');
end;Si tus registros muestran solicitudes privadas de Huobi o HTX que fallaban de forma intermitente sin un desencadenante claro, es muy probable que esta sea la razón, sobre todo si tus servidores no funcionan en UTC.
Suscripciones privadas perdidas al reconectar
Huobi fue también uno de varios clientes de exchanges afectados por un defecto de reconexión independiente, corregido en la misma revisión: después de que el WatchDog reconectaba, las suscripciones privadas (órdenes, saldos, ejecuciones) no se volvían a reproducir. La reconexión en sí se completaba con éxito y quedaba registrada como tal, de modo que no había ninguna indicación de que los feeds privados que venías recibiendo antes de la desconexión hubieran desaparecido silenciosamente. Esa reproducción ahora forma parte de la misma ruta de resuscripción que ya restauraba las suscripciones de datos de mercado públicos tras una reconexión.
Actualización
Ambas correcciones son directas. No hay ninguna propiedad que configurar ni código que cambiar: la firma ahora es simplemente correcta, y la reproducción tras la reconexión ahora incluye tus suscripciones privadas.
¿Preguntas, comentarios o ayuda con la migración? Ponte en contacto — recibirás una respuesta de las personas que escribieron el código.