In 2026.9 zijn vier afzonderlijke Kraken-defecten opgelost, en geen daarvan is het type dat je opvalt bij één keer door de code lezen. Elk defect komt alleen naar boven onder een specifieke voorwaarde: het verkeerde endpoint bij het verbinden, een requestbody die de machine nooit verlaat, een reconnect die een paar honderd milliseconden te vroeg gebeurt. Alle vier zijn opgelost, en alle vier zijn de moeite waard om te begrijpen, want het faalgedrag lijkt in elk geval op iets heel anders.
De spot-client sprak v1 tegen een v2-endpoint
TsgcWSAPI_Kraken bouwt en verwerkt het v1-schema: event, pair, subscription, subscriptionStatus, systemStatus. Dat schema bestaat om een reden, het is waar elke subscribe-aanroep en elke event handler van dit component tegen geschreven is. Het endpoint waarmee verbonden werd, stond echter standaard op Kraken's v2-WebSocket, dat een geheel ander schema spreekt: method, params, channel, type. De verbinding ging zonder fout open. Er kwam alleen nooit een enkele subscription-acknowledgement of status event uit, omdat de server antwoordde in een vorm die de client nooit verwerkt.
Kraken.Version staat nu standaard op 1, en het component kiest het bijbehorende v1-endpoint:
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;Als jouw applicatie op de een of andere manier vertrouwde op de oude, stilzwijgend verkeerde standaardwaarde, dan betekent dat dat er ook nooit echt v1-events ontvangen werden, dus er is niets werkends om vandaag te bewaren. Het expliciet instellen van Kraken.Version := 2 verbindt nog steeds met het v2-endpoint, met RawMessages ingeschakeld en de payload afgehandeld in OnKrakenData of OnMessage, voor wie doelbewust tegen dat schema bouwt.
Futures-orders als GET verzonden, body genegeerd
Dit defect is stiller en ernstiger. Elke private request op de Kraken Futures REST-client, het versturen van een order, het bewerken ervan, het annuleren ervan, een transfer, een withdrawal, ging als een HTTP GET uit. De gesigneerde requestbody werd correct opgebouwd, berekend, geformatteerd, klaar om te versturen, en werd vervolgens genegeerd, omdat een GET-request geen body heeft om hem in te plaatsen. Kraken ontving een GET zonder parameters en wees deze af of negeerde hem. Geen van deze aanroepen werkte.
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 en WithdrawalToSpotWallet lopen nu allemaal via het private POST-pad, met de gesigneerde body daadwerkelijk aan de request gehecht.
Private subscriptions verloren bij reconnect
De WatchDog voert een reconnect uit, het log toont een schone reconnectie, en vanaf dat moment zijn je orders-, balance- en fills-kanalen gewoon verdwenen. Er is geen enkele fout. Er wordt niets gelogd. De reconnect zag er volledig geslaagd uit, omdat de verbinding zelf ook daadwerkelijk slaagde, het waren alleen de private subscriptions van vóór de disconnect die nadien nooit opnieuw werden afgespeeld. Dit trof zowel Kraken spot als Kraken Futures, samen met verschillende andere exchange-clients die in dezelfde ronde zijn opgelost. Het maakt nu deel uit van de standaard resubscribe-replay, hetzelfde pad dat je publieke marktdata-subscriptions na een reconnect al herstelt.
Futures die opnieuw abonneerden voordat de sessie geauthenticeerd was
Een nauw verwant defect, specifiek voor Kraken Futures: na een reconnect kon de replay van actieve subscriptions draaien vóórdat de authenticatie-handshake daadwerkelijk voltooid was. De subscribe-requests gingen uit op een sessie die Kraken nog niet geauthenticeerd had, waardoor de private ervan werden afgewezen, opnieuw zonder dat er iets in de client op de oorzaak wees. De replay wacht nu tot de authenticatie voltooid is voordat hij opnieuw abonneert.
Upgraden
Alle vier de fixes zijn drop-in, er is geen API om naartoe te migreren. De enige gedragswijziging om je bewust van te zijn, is de omslag van de Kraken.Version-standaardwaarde van de vorige, feitelijk niet-functionele waarde naar 1; als je code al expliciet Version := 2 instelt, verandert er niets voor jou.
Vragen, feedback of hulp bij migratie? Neem contact op — je krijgt antwoord van de mensen die de code hebben geschreven.