AiHummer
English▾
Sign inAccount
v1.1.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Architecture/Reliable delivery and recovery

Reliable delivery and recovery

v1.1.x · updated 2026-07-27

AiHummer is designed to finish a reply even when a channel connection briefly drops or the instance restarts. This page describes the visible behaviour and the actions an administrator should take. It intentionally does not require you to understand the platform’s internal delivery machinery.

What users should see

After a user sends a message:

  1. The session shows the message that was accepted.
  2. The agent processes it and produces one visible reply.
  3. If the channel is temporarily unavailable, delivery is retried.
  4. When the channel returns, the reply appears without the user having to send the same request again.

The same request should not produce duplicate visible replies. If a client reconnects, it may reload recent history, but the conversation itself remains one continuous session.

What happens after a restart

An instance update, host reboot or unexpected restart should not make an accepted request disappear. Work that can safely continue is resumed after the instance becomes healthy. The user should see either the completed reply or a clear failure state that can be retried.

[!NOTE] Do not immediately repeat a request while the instance is still recovering. First wait for the health status to return to normal and refresh the session. This avoids creating a genuinely new request alongside the recovering one.

If a reply does not arrive

  1. Open Status and confirm that the instance and the affected channel are healthy.
  2. Open the session and refresh it once.
  3. Check Notifications for a delivery or channel warning.
  4. Send a short new test message only after the previous request has a visible success or failure result.
  5. If the problem repeats, record the time, session, channel and visible error, then contact support. Never paste API keys or channel secrets into a ticket.

For channel-specific recovery, open the corresponding guide under Channels. For instance health checks, see Systemd and health checks.

What administrators should monitor

Watch user-visible outcomes rather than implementation details:

  • replies stop reaching one channel while other channels work;
  • sessions remain in progress unusually long;
  • the instance repeatedly changes between healthy and unavailable;
  • notifications report repeated delivery failures;
  • users see duplicate replies for one accepted request.

These symptoms, together with their timestamps, are sufficient for support to diagnose the problem.

Where to next