Huobi et HTX : la correction d'un horodatage de signature qui échouait seulement une partie de la journée

Certains bugs échouent à chaque fois. D'autres échouent selon un horaire précis. Le défaut de signature Huobi et HTX corrigé dans la 2026.9 appartenait à la seconde catégorie, ce qui le rendait bien plus difficile à cerner : sur un hôte fonctionnant hors UTC, les requêtes privées échouaient pendant une partie de chaque journée et fonctionnaient le reste du temps, ce qui ressemble exactement à un problème d'authentification intermittent, jusqu'à ce que quelqu'un remarque que le schéma coïncide avec l'horloge.

Un horodatage construit à partir de deux horloges différentes

Huobi et HTX exigent tous deux que la requête signée porte un horodatage en UTC, au format yyyy-MM-ddTHH:mm:ss. La routine de signature de TsgcWS_API_Huobi_Base, partagée par TsgcWSAPI_Huobi et TsgcWSAPI_HTX, construisait cet horodatage à partir de deux sources différentes : la partie date provenait de l'horloge système locale, la partie heure provenait de l'UTC. Pendant la majeure partie de la journée sur la plupart des machines, la date locale et la date UTC ont la même valeur, donc rien ne semblait anormal. Près de minuit UTC, sur tout hôte dont le décalage de fuseau horaire local le plaçait de l'autre côté de cette frontière, la date et l'heure cessaient de correspondre, la signature calculée de son côté par Huobi ne correspondait plus, et la requête était rejetée.

La correction tire à la fois la date et l'heure de la même valeur 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;

Il n'y a rien à configurer. TsgcWSAPI_Huobi et TsgcWSAPI_HTX appellent tous deux cette même routine de signature, donc les deux sont corrigés ensemble :

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 vos journaux montrent des requêtes privées Huobi ou HTX qui échouaient de manière apparemment aléatoire, sans déclencheur évident, c'est très probablement la raison, en particulier si vos serveurs ne fonctionnent pas en UTC.

Abonnements privés perdus lors de la reconnexion

Huobi était également l'un des plusieurs clients d'échange affectés par un défaut de reconnexion distinct, corrigé dans la même passe : après une reconnexion du WatchDog, les abonnements privés, ordres, soldes, exécutions, n'étaient pas rejoués. La reconnexion elle-même réussissait et était journalisée comme telle, si bien que rien n'indiquait que les flux privés que vous receviez avant la déconnexion avaient désormais silencieusement disparu. Ce rejeu fait désormais partie du même mécanisme de réabonnement qui restaure déjà les abonnements aux données de marché publiques après une reconnexion.

Mise à jour

Les deux corrections s'appliquent automatiquement. Il n'y a aucune propriété à définir ni aucun code à modifier, la signature est désormais tout simplement correcte, et le rejeu après reconnexion inclut désormais vos abonnements privés.

Des questions, des retours, ou besoin d'aide pour la migration ? Contactez-nous — vous recevrez une réponse de la part des personnes qui ont écrit le code.