Manche Fehler treten jedes Mal auf. Manche folgen einem Zeitplan. Der in 2026.9 behobene Signaturfehler bei Huobi und HTX gehörte zur zweiten Sorte, was ihn deutlich schwerer aufzuspüren machte: Auf einem Host außerhalb der UTC-Zeitzone schlugen private Anfragen einen Teil jedes Tages fehl und funktionierten den Rest der Zeit, was genau wie ein sporadisches Authentifizierungsproblem aussieht, bis jemand bemerkt, dass sich das Muster mit der Uhrzeit deckt.
Ein Zeitstempel aus zwei verschiedenen Uhren
Sowohl Huobi als auch HTX verlangen, dass die signierte Anfrage einen Zeitstempel in UTC trägt, formatiert als yyyy-MM-ddTHH:mm:ss. Die Signierroutine in TsgcWS_API_Huobi_Base, die sich TsgcWSAPI_Huobi und TsgcWSAPI_HTX teilen, baute diesen Zeitstempel aus zwei verschiedenen Quellen zusammen: Der Datumsanteil stammte von der lokalen Systemuhr, der Zeitanteil von UTC. Auf den meisten Rechnern sind lokales Datum und UTC-Datum den größten Teil des Tages identisch, sodass nichts auffiel. Nahe Mitternacht UTC, auf jedem Host, dessen lokale Zeitzonenverschiebung ihn auf die andere Seite dieser Grenze brachte, stimmten Datum und Zeit nicht mehr überein, die Signatur, die Huobi auf seiner Seite berechnete, passte nicht mehr, und die Anfrage wurde abgelehnt.
Die Korrektur entnimmt sowohl Datum als auch Zeit demselben UTC-Wert:
uses
sgcBase_Helpers;
var
vUTC: TDateTime;
vTimeStamp: string;
begin
vUTC := sgcGetDateTimeAsUTC;
vTimeStamp := FormatDateTime('yyyy-mm-dd', vUTC) + 'T' +
FormatDateTime('hh:nn:ss', vUTC);
end;
Es gibt nichts zu konfigurieren. TsgcWSAPI_Huobi und TsgcWSAPI_HTX rufen beide dieselbe Signierroutine auf, sodass beide gemeinsam korrigiert sind:
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;
Wenn Ihre Logs zeigen, dass private Huobi- oder HTX-Anfragen auf eine Weise fehlschlugen, die kam und ging, ohne einen klaren Auslöser, ist das sehr wahrscheinlich der Grund, besonders wenn Ihre Server nicht in UTC laufen.
Private Abonnements bei Wiederverbindung verloren
Huobi gehörte außerdem zu mehreren Exchange-Clients, die von einem separaten Reconnect-Fehler betroffen waren, der im selben Durchgang behoben wurde: Nachdem der WatchDog die Verbindung wiederhergestellt hatte, wurden private Abonnements, Orders, Kontostände und Fills nicht erneut übertragen. Die Wiederverbindung selbst gelang und wurde auch so protokolliert, sodass nichts darauf hindeutete, dass die privaten Feeds, die Sie vor der Trennung empfangen hatten, nun stillschweigend verschwunden waren. Diese erneute Übertragung ist jetzt Teil desselben Resubscribe-Pfads, der bereits die öffentlichen Marktdaten-Abonnements nach einer Wiederverbindung wiederherstellt.
Upgrade
Beide Korrekturen sind Drop-in. Es gibt keine Eigenschaft zu setzen und keinen Code zu ändern, die Signatur ist jetzt einfach korrekt, und die erneute Übertragung nach der Wiederverbindung schließt jetzt Ihre privaten Abonnements ein.
Fragen, Feedback oder Hilfe bei der Migration? Kontaktieren Sie uns — Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.
