Skip to main content
hiloop treats telemetry as data you cannot afford to lose. When an event is accepted, it is recoverable — an accepted event becomes queryable and stays queryable, across restarts, upgrades, and unclean failures. This page explains the guarantees so you know what an acknowledgement means and what to do when ingest pushes back.

​
The acknowledgement contract

Every ingest path — hiloop run capture, direct event ingest, and hiloop annotations add — returns an event_id only after the event is durably recorded. The acknowledgement is the guarantee, not a hint:
  • Accepted means durable. By the time you hold an event_id, the event is on durable storage. A crash, restart, or upgrade immediately afterward does not lose it.
  • Accepted means queryable. An accepted event is visible to SQL queries and live tail right away — you can read your own writes without waiting for a flush.
  • No acknowledgement means not accepted. If a request fails, the event was not committed. It is safe to retry.
Because acknowledgement follows durability, “acked ⇒ eventually queryable” holds even in the worst cases below.

​
Retries are always safe

Every event carries a stable event_id. Ingest deduplicates on it, so re-sending an event that may or may not have been accepted never creates a duplicate. Retry freely — the query surface shows each event once.

​
Backpressure, not silent loss

Under sustained overload hiloop protects durability by pushing back, never by quietly dropping accepted data. When an ingest buffer is saturated, new requests are rejected before they are acknowledged, with a retryable error: These are transient. The hiloop CLI and the capture interceptor treat them as spool-and-retry signals and resend automatically, so a burst becomes a brief slowdown rather than a gap. A rejected request was never accepted — nothing is lost, and nothing is acknowledged that later disappears.

​
Surviving restarts, upgrades, and crashes

Accepted events are protected by two layers of durable storage: a write-ahead log the event lands in before it is acknowledged, and a durable raw archive that holds every accepted record. Together they make recovery robust across the failure modes that matter: The result: whatever accepted your event, and whatever happens to the process next, the event_id you were handed remains queryable.

​
Availability during rollouts

Deployments hand off between processes rather than taking ingest down. A rollout is a brief handoff measured in seconds or less, not an outage, and events sent across the handoff are deduplicated on event_id — so a retry during a deploy is safe and does not duplicate.

​
What this means for you

  • Trust the event_id. If you got one, the event is safe. Read-back verification will find it.
  • Retry on error. A failed or throttled request was not accepted; resend it. Deduplication makes retries free of duplicates.
  • Let the client spool. The CLI and interceptor already back off and resend on throttling — you rarely need to handle it yourself.
For where these events land and how to query them, see the observability overview and query telemetry. For backup and disaster-recovery ownership by deployment model, see backup and restore.