AiHummer jest zaprojektowany tak, aby dokończyć odpowiedź nawet wtedy, gdy połączenie kanału chwilowo zanika lub instancja zostaje ponownie uruchomiona. Ta strona opisuje widoczne zachowanie oraz działania, które powinien podjąć administrator. Celowo nie wymaga od ciebie zrozumienia wewnętrznego mechanizmu dostarczania platformy.
Co użytkownicy powinni zobaczyć
Po wysłaniu wiadomości przez użytkownika:
Sesja pokazuje komunikat, który został zaakceptowany.
Agent przetwarza to i generuje jedną widoczną odpowiedź.
Jeśli kanał jest tymczasowo niedostępny, dostawa jest ponawiana.
Gdy kanał wraca, odpowiedź pojawia się bez konieczności wysyłania przez użytkownika
ten sam wniosek ponownie.
To samo zapytanie nie powinno generować zduplikowanych widocznych odpowiedzi. Jeśli klient ponownie się połączy, może załadować ostatnią historię, ale sama rozmowa pozostaje jedną ciągłą sesją.
Co się dzieje po ponownym uruchomieniu
Aktualizacja instancji, ponowne uruchomienie hosta lub nieoczekiwany restart nie powinny powodować zniknięcia zaakceptowanego żądania. Praca, którą można bezpiecznie kontynuować, jest wznawiana po przywróceniu zdrowia instancji. Użytkownik powinien zobaczyć albo ukończoną odpowiedź, albo wyraźny stan awarii, który można ponowić.
[!NOTE]
Nie powtarzaj natychmiast żądania, gdy instancja wciąż się regeneruje.
Najpierw poczekaj, aż stan zdrowia wróci do normy i odśwież sesję.
To pozwala uniknąć tworzenia naprawdę nowego żądania obok odzyskiwanego.
Jeśli odpowiedź nie nadejdzie
Otwórz Status i potwierdź, że instancja i dotknięty kanał są
zdrowy.
Otwórz sesję i odśwież ją raz.
Sprawdź Powiadomienia dla ostrzeżenia dotyczącego dostawy lub kanału.
Wyślij krótką nową wiadomość testową dopiero po tym, jak poprzednie żądanie będzie widoczne
wynik sukcesu lub porażki.
Jeśli problem się powtórzy, zanotuj czas, sesję, kanał i widoczny błąd,
Skontaktuj się wtedy z pomocą techniczną. Nigdy nie wklejaj kluczy API ani sekretów kanału do zgłoszenia.
Dla odzyskiwania specyficznego dla kanału, otwórz odpowiedni przewodnik w Kanały. Na przykład kontrole stanu zdrowia, zobacz Systemd i kontrole stanu.
Co powinni monitorować administratorzy
Obserwuj widoczne dla użytkownika rezultaty, a nie szczegóły implementacji:
odpowiedzi przestają docierać do jednego kanału, podczas gdy inne kanały działają;
sesje pozostają w toku wyjątkowo długo;
instancja wielokrotnie zmienia się między zdrową a niedostępną;
powiadomienia zgłaszają powtarzające się błędy dostarczenia;
użytkownicy widzą zduplikowane odpowiedzi na jedno zaakceptowane żądanie.
Te objawy, wraz z ich znacznikami czasu, są wystarczające, aby dział wsparcia mógł zdiagnozować problem.
AiHummer jest zaprojektowany tak, aby dokończyć odpowiedź nawet wtedy, gdy połączenie kanału chwilowo zanika lub instancja zostaje ponownie uruchomiona. Ta strona opisuje **widoczne zachowanie** oraz działania, które powinien podjąć administrator. Celowo nie wymaga od ciebie zrozumienia wewnętrznego mechanizmu dostarczania platformy.
## Co użytkownicy powinni zobaczyć
Po wysłaniu wiadomości przez użytkownika:
1. Sesja pokazuje komunikat, który został zaakceptowany.
2. Agent przetwarza to i generuje jedną widoczną odpowiedź.
3. Jeśli kanał jest tymczasowo niedostępny, dostawa jest ponawiana.
4. Gdy kanał wraca, odpowiedź pojawia się bez konieczności wysyłania przez użytkownika
ten sam wniosek ponownie.
To samo zapytanie nie powinno generować zduplikowanych widocznych odpowiedzi. Jeśli klient ponownie się połączy, może załadować ostatnią historię, ale sama rozmowa pozostaje jedną ciągłą sesją.
## Co się dzieje po ponownym uruchomieniu
Aktualizacja instancji, ponowne uruchomienie hosta lub nieoczekiwany restart nie powinny powodować zniknięcia zaakceptowanego żądania. Praca, którą można bezpiecznie kontynuować, jest wznawiana po przywróceniu zdrowia instancji. Użytkownik powinien zobaczyć albo ukończoną odpowiedź, albo wyraźny stan awarii, który można ponowić.
> [!NOTE]
> Nie powtarzaj natychmiast żądania, gdy instancja wciąż się regeneruje.
> Najpierw poczekaj, aż stan zdrowia wróci do normy i odśwież sesję.
> To pozwala uniknąć tworzenia naprawdę nowego żądania obok odzyskiwanego.
## Jeśli odpowiedź nie nadejdzie
1. Otwórz **Status** i potwierdź, że instancja i dotknięty kanał są
zdrowy.
2. Otwórz sesję i odśwież ją raz.
3. Sprawdź **Powiadomienia** dla ostrzeżenia dotyczącego dostawy lub kanału.
4. Wyślij krótką nową wiadomość testową dopiero po tym, jak poprzednie żądanie będzie widoczne
wynik sukcesu lub porażki.
5. Jeśli problem się powtórzy, zanotuj czas, sesję, kanał i widoczny błąd,
Skontaktuj się wtedy z pomocą techniczną. Nigdy nie wklejaj kluczy API ani sekretów kanału do zgłoszenia.
Dla odzyskiwania specyficznego dla kanału, otwórz odpowiedni przewodnik w [Kanały](/pl/v1.0/webui/channels). Na przykład kontrole stanu zdrowia, zobacz [Systemd i kontrole stanu](/pl/v1.0/operations/systemd-health).
## Co powinni monitorować administratorzy
Obserwuj widoczne dla użytkownika rezultaty, a nie szczegóły implementacji:
- odpowiedzi przestają docierać do jednego kanału, podczas gdy inne kanały działają;
- sesje pozostają w toku wyjątkowo długo;
- instancja wielokrotnie zmienia się między zdrową a niedostępną;
- powiadomienia zgłaszają powtarzające się błędy dostarczenia;
- użytkownicy widzą zduplikowane odpowiedzi na jedno zaakceptowane żądanie.
Te objawy, wraz z ich znacznikami czasu, są wystarczające, aby dział wsparcia mógł zdiagnozować problem.
## Dokąd dalej
- [Bramka i silnik obrotowy](/pl/v1.0/architecture/gateway-turn-engine)
- [Obserwowalność](/pl/v1.0/operations/observability)
- [Kanały](/pl/v1.0/webui/channels)
