AiHummer är designad för att slutföra ett svar även när en kanalanslutning tillfälligt bryts eller instansen startar om. Denna sida beskriver synligt beteende och de åtgärder en administratör bör vidta. Det kräver medvetet inte att du förstår plattformens interna leveransmekanism.
Vad användare ska se
Efter att en användare skickar ett meddelande:
Sessionen visar meddelandet som accepterades.
Agenten bearbetar det och producerar ett synligt svar.
Om kanalen är tillfälligt otillgänglig försöks leverans på nytt.
När kanalen återvänder visas svaret utan att användaren behöver skicka
samma begäran igen.
Samma förfrågan bör inte producera dubbletter av synliga svar. Om en klient återansluter kan den ladda om den senaste historiken, men själva konversationen förblir en kontinuerlig session.
Vad händer efter en omstart
En uppdatering av instansen, omstart av värden eller oväntad omstart ska inte få en accepterad begäran att försvinna. Arbete som säkert kan fortsätta återupptas efter att instansen blir frisk. Användaren ska se antingen det kompletta svaret eller ett tydligt felstatus som kan försöka igen.
[!NOTE]
Upprepa inte omedelbart en förfrågan medan instansen fortfarande återhämtar sig.
Vänta först på att hälsotillståndet återgår till det normala och uppdatera sessionen.
Detta undviker att skapa en genuint ny begäran tillsammans med den som återställs.
Om ett svar inte kommer
Öppen Status och bekräfta att instansen och den påverkade kanalen är
hälsosam.
Öppna sessionen och uppdatera den en gång.
Kontrollera Aviseringar för en leverans- eller kanalvarning.
Skicka ett kort nytt testmeddelande endast efter att den föregående begäran har en synlig
framgångs- eller misslyckanderesultat.
Om problemet upprepas, registrera tid, session, kanal och synligt fel,
kontakta då supporten. Klistra aldrig in API-nycklar eller kanalhemligheter i en supportförfrågan.
AiHummer är designad för att slutföra ett svar även när en kanalanslutning tillfälligt bryts eller instansen startar om. Denna sida beskriver **synligt beteende** och de åtgärder en administratör bör vidta. Det kräver medvetet inte att du förstår plattformens interna leveransmekanism.
## Vad användare ska se
Efter att en användare skickar ett meddelande:
1. Sessionen visar meddelandet som accepterades.
2. Agenten bearbetar det och producerar ett synligt svar.
3. Om kanalen är tillfälligt otillgänglig försöks leverans på nytt.
4. När kanalen återvänder visas svaret utan att användaren behöver skicka
samma begäran igen.
Samma förfrågan bör inte producera dubbletter av synliga svar. Om en klient återansluter kan den ladda om den senaste historiken, men själva konversationen förblir en kontinuerlig session.
## Vad händer efter en omstart
En uppdatering av instansen, omstart av värden eller oväntad omstart ska inte få en accepterad begäran att försvinna. Arbete som säkert kan fortsätta återupptas efter att instansen blir frisk. Användaren ska se antingen det kompletta svaret eller ett tydligt felstatus som kan försöka igen.
> [!NOTE]
> Upprepa inte omedelbart en förfrågan medan instansen fortfarande återhämtar sig.
> Vänta först på att hälsotillståndet återgår till det normala och uppdatera sessionen.
> Detta undviker att skapa en genuint ny begäran tillsammans med den som återställs.
## Om ett svar inte kommer
1. Öppen **Status** och bekräfta att instansen och den påverkade kanalen är
hälsosam.
2. Öppna sessionen och uppdatera den en gång.
3. Kontrollera **Aviseringar** för en leverans- eller kanalvarning.
4. Skicka ett kort nytt testmeddelande endast efter att den föregående begäran har en synlig
framgångs- eller misslyckanderesultat.
5. Om problemet upprepas, registrera tid, session, kanal och synligt fel,
kontakta då supporten. Klistra aldrig in API-nycklar eller kanalhemligheter i en supportförfrågan.
För kanal-specifik återställning, öppna motsvarande guide under [Kanaler](/sv/v1.0/webui/channels). Till exempel hälsokontroller, se [Systemd och hälsokontroller](/sv/v1.0/operations/systemd-health).
## Vad administratörer bör övervaka
Titta på användar-synliga resultat istället för implementeringsdetaljer:
- svar slutar nå en kanal medan andra kanaler fungerar;
- sessioner fortsätter ovanligt länge;
- instansen växlar upprepade gånger mellan frisk och otillgänglig;
- aviseringar rapporterar upprepade leveransfel;
- användare ser dubblettsvar för en accepterad förfrågan.
Dessa symptom, tillsammans med deras tidsstämplar, är tillräckliga för att supporten ska kunna diagnostisera problemet.
## Vart härnäst
- [Gateway och svängmotor](/sv/v1.0/architecture/gateway-turn-engine)
- [Observerbarhet](/sv/v1.0/operations/observability)
- [Kanaler](/sv/v1.0/webui/channels)
