Alguns bugs falham sempre. Outros falham conforme um horário. O defeito de assinatura da Huobi e da HTX corrigido na versão 2026.9 era do segundo tipo, e isso tornava muito mais difícil identificá-lo: em um host rodando fora do UTC, as requisições privadas falhavam durante parte de cada dia e funcionavam no restante dele, o que parece exatamente um problema intermitente de autenticação até alguém perceber que o padrão coincide com o relógio.
Um timestamp construído a partir de dois relógios diferentes
Tanto a Huobi quanto a HTX exigem que a requisição assinada carregue um timestamp em UTC, formatado como yyyy-MM-ddTHH:mm:ss. A rotina de assinatura em TsgcWS_API_Huobi_Base, compartilhada por TsgcWSAPI_Huobi e TsgcWSAPI_HTX, construía esse timestamp a partir de duas fontes diferentes: a parte da data vinha do relógio local do sistema, e a parte da hora vinha do UTC. Durante a maior parte do dia, na maioria das máquinas, a data local e a data UTC são o mesmo valor, então nada parecia errado. Perto da meia-noite UTC, em qualquer host cujo fuso horário local o colocasse do outro lado dessa fronteira, a data e a hora deixavam de coincidir entre si, a assinatura calculada pela Huobi do seu próprio lado não correspondia, e a requisição era rejeitada.
A correção obtém tanto a data quanto a hora a partir do mesmo 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;
Não há nada para configurar. TsgcWSAPI_Huobi e TsgcWSAPI_HTX chamam essa mesma rotina de assinatura, então ambas são corrigidas juntas:
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;
Se os seus logs mostram requisições privadas da Huobi ou da HTX falhando de um jeito que parecia ir e vir sem um gatilho claro, é bem provável que seja por isso, principalmente se os seus servidores não rodam em UTC.
Assinaturas privadas perdidas na reconexão
A Huobi também foi um dos vários clientes de exchange afetados por um defeito de reconexão separado, corrigido na mesma leva: depois que o WatchDog reconectava, as assinaturas privadas, ordens, saldos, execuções, não eram reenviadas. A reconexão em si era bem-sucedida e registrada como tal no log, então não havia nada que indicasse que os feeds privados que você vinha recebendo antes da desconexão agora tinham simplesmente desaparecido. Esse reenvio agora faz parte do mesmo caminho de reinscrição que já restaura as assinaturas de dados públicos de mercado após uma reconexão.
Atualizando
As duas correções são diretas. Não há propriedade para definir nem código para alterar, a assinatura simplesmente agora está correta, e o reenvio na reconexão agora inclui suas assinaturas privadas.
Dúvidas, feedback ou ajuda com a migração? Entre em contato — você receberá uma resposta de quem escreveu o código.
