Vier separate Kraken-Fehler sind in 2026.9 eingeflossen, und keiner von ihnen ist die Art von Fehler, die man beim einmaligen Lesen des Codes entdeckt. Jeder tritt nur unter einer bestimmten Bedingung auf: der falsche Endpunkt beim Verbindungsaufbau, ein Request-Body, der die Maschine nie verlässt, ein Reconnect, der ein paar hundert Millisekunden zu früh erfolgt. Alle vier sind behoben, und es lohnt sich, alle vier zu verstehen, denn das Fehlerbild sieht in jedem Fall nach etwas völlig anderem aus.
Der Spot-Client sprach v1 mit einem v2-Endpunkt
TsgcWSAPI_Kraken erstellt und parst das v1-Schema: event, pair, subscription, subscriptionStatus, systemStatus. Dieses Schema existiert aus gutem Grund, es ist das, wogegen jeder Subscribe-Aufruf und jeder Event-Handler dieser Komponente geschrieben ist. Der Endpunkt, mit dem sie sich verband, war jedoch standardmäßig der v2-WebSocket von Kraken, der ein völlig anderes Schema spricht: method, params, channel, type. Die Verbindung wurde ohne Fehler geöffnet. Sie lieferte lediglich nie eine einzige Subscription-Bestätigung oder ein Status-Event, weil der Server in einer Form antwortete, die der Client nie parst.
Kraken.Version ist jetzt standardmäßig 1, und die Komponente wählt den passenden v1-Endpunkt:
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;Falls Ihre Anwendung sich irgendwie auf den alten, stillschweigend falschen Standardwert verlassen hat, bedeutet das, dass sie auch nie tatsächlich v1-Events empfangen hat, es gibt also nichts Funktionierendes, das heute erhalten werden müsste. Ein explizites Setzen von Kraken.Version := 2 verbindet weiterhin mit dem v2-Endpunkt, wobei RawMessages aktiviert ist und die Payload in OnKrakenData oder OnMessage verarbeitet wird, für alle, die absichtlich gegen dieses Schema entwickeln.
Futures-Orders wurden als GET gesendet, Body verworfen
Dieser Fehler ist unauffälliger und schwerwiegender. Jede private Anfrage des Kraken-Futures-REST-Clients, das Senden einer Order, das Bearbeiten einer Order, das Stornieren einer Order, ein Transfer, eine Auszahlung, ging als HTTP-GET hinaus. Der signierte Request-Body wurde korrekt erstellt, berechnet, formatiert, sendebereit, und dann verworfen, weil ein GET-Request keinen Body hat, in den er hineinpasst. Kraken erhielt ein GET ohne Parameter und lehnte es ab oder ignorierte es. Keiner dieser Aufrufe funktionierte.
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 und WithdrawalToSpotWallet laufen jetzt alle über den privaten POST-Pfad, wobei der signierte Body tatsächlich an die Anfrage angehängt wird.
Private Subscriptions bei Reconnect verloren
Der WatchDog stellt die Verbindung wieder her, das Log zeigt einen sauberen Reconnect, und ab diesem Zeitpunkt sind Ihre Orders-, Balance- und Fills-Kanäle einfach verschwunden. Kein Fehler. Kein Log-Eintrag. Der Reconnect wirkte vollkommen erfolgreich, denn die Verbindung selbst kam tatsächlich zustande, nur die vor der Trennung ausgestellten privaten Subscriptions wurden danach nie erneut abonniert. Das betraf Kraken Spot und Kraken Futures gleichermaßen, zusammen mit mehreren anderen Exchange-Clients, die im selben Durchgang behoben wurden. Es ist jetzt Teil des Standard-Resubscribe-Replays, desselben Pfads, der bereits Ihre öffentlichen Marktdaten-Subscriptions nach einem Reconnect wiederherstellt.
Futures-Resubscribe vor abgeschlossener Session-Authentifizierung
Ein eng verwandter Fehler, spezifisch für Kraken Futures: Nach einem Reconnect konnte der Replay der aktiven Subscriptions ablaufen, bevor der Authentifizierungs-Handshake tatsächlich abgeschlossen war. Die Subscribe-Requests gingen auf einer Session hinaus, die Kraken noch nicht authentifiziert hatte, sodass die privaten Requests abgelehnt wurden, wiederum ohne jeden Hinweis im Client, woran das lag. Der Replay wartet jetzt, bis die Authentifizierung abgeschlossen ist, bevor er erneut abonniert.
Aktualisierung
Alle vier Fixes sind Drop-in, es gibt keine API zu migrieren. Die eine Verhaltensänderung, die zu beachten ist, ist der Wechsel des Kraken.Version-Standardwerts vom vorherigen, faktisch funktionslosen Wert auf 1; wenn Ihr Code bereits explizit Version := 2 setzt, ändert sich für Sie nichts.
Fragen, Feedback oder Hilfe bei der Migration? Kontaktieren Sie uns — Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.