Kunden sehen einen ehrlichen ausstehenden oder wiederverbindenden Zustand und angenommene Nachrichten werden weder dupliziert noch still verworfen.
Stabile Idempotency Keys verwenden
Erzeugen Sie einen Idempotency Key pro Kundenabsicht und behalten Sie ihn, bis das SDK ein angenommenes Ergebnis meldet. Die native Engine speichert den exakten Request-Body, Zeitstempel und Schlüssel vor dem Schreiben in der kontogebundenen dauerhaften Outbox. Erzeugen Sie bei verzögerter Bestätigung keinen neuen Schlüssel.
Das Web-Widget besitzt die kunden sichtbare Wiederverbindungs- und Warteanzeige. Mobile Headless-Clients stellen resumeSession, refresh und flushOutbox bereit, damit der Host nach einem frischen Token desselben Kontos eine ausdrückliche Wiederholung anbieten kann. Der folgende Code verwendet die TypeScript-Wrapperform (startSession(message, options) und sendMessage(text, idempotencyKey)). In Dart gelten dieselben Vorgänge mit sendMessage(text, idempotencyKey: key). Direkte Swift- und Kotlin-Clients verwenden ihre Plattform-DTOs mit derselben Regel für stabile Schlüssel, wie in den jeweiligen Plattformreferenzen gezeigt.
const sessionKey = `order-${orderId}-session-${attemptId}`;
const messageKey = `order-${orderId}-question-${attemptId}`;
// Persist each key with its own user intent until the SDK acknowledges it.
await client.startSession("I need help with my order", {
idempotencyKey: sessionKey,
});
await client.sendMessage("The order number is ORD-42", messageKey);
// Call this only from an explicit "Retry the same message" control after
// connectivity and a fresh token for the same account are available.
async function retryPendingMessage() {
await client.resumeSession();
await client.flushOutbox();
}Ausstehende, abgelehnte und doppelte Ergebnisse unterscheiden
Ein Netzwerk- oder Drosselungsfehler kann die Annahme unklar lassen. Bewahren Sie daher die ursprüngliche Mutation für eine ausdrückliche Wiederholung mit demselben Schlüssel auf. field-invalid, payload-too-large, message-rejected und idempotency-conflict erfordern Hostkorrektur oder Untersuchung und dürfen nicht automatisch mit einem anderen Schlüssel wiedergegeben werden.
Ein session-expired-Ergebnis benötigt vor der Wiederholung ein frisches signiertes Token für dasselbe Konto. Rufen Sie resetSession bei einem vorübergehenden Ausfall nicht auf, da reset die dauerhafte Sitzung und ausstehende Mutationen absichtlich löscht.
Offline-Zustand sichtbar machen
- Zeigen Sie eine Warte- oder Wiederverbindungsbeschriftung, die an den Ladezustand des SDK gebunden ist, und lassen Sie den Composer nur verfügbar, wenn der Host eine weitere Absicht sicher annehmen kann.
- Bieten Sie nach Wiederherstellung von Verbindung und Authentifizierung an, dieselbe Nachricht erneut zu senden. Halten Sie den ursprünglichen Idempotency Key hinter der Steuerung und deaktivieren Sie doppeltes Senden während der Verarbeitung.
- Wenn der Kunde die Unterhaltung bewusst verwirft, rufen Sie resetSession auf und machen Sie das Ergebnis sichtbar. Löschen Sie dauerhaften Zustand niemals nur, weil die App in den Hintergrund gelangt.