/**
 * The one place anything leaves the machine.
 *
 * READS THE FILE THE RECORDER ALREADY WROTE, rather than sending per event. An
 * upload on the hot path would put a network round trip inside a tool call, and
 * the first slow or unreachable receiver would be indistinguishable from a slow
 * tool. Batching from the log also means a machine that is offline for a week
 * loses nothing: the events are already on disk, and the next flush sends them.
 *
 * EVERY EVENT IS RE-VALIDATED HERE. The file is on disk and could have been
 * edited, truncated or appended to by anything with write access to the home
 * directory, so each line is parsed and rebuilt through `sanitiseProperties`
 * before it is allowed into a request body. The guarantee in event.ts is about
 * what we construct; this is about what we transmit, and they are not the same
 * claim once a file sits between them.
 *
 * IT MAY NEVER THROW INTO ITS CALLER, for the reason recorder.ts gives. Every
 * failure -- no key, no consent, unparseable file, refused request -- returns a
 * result saying what happened, and `doctor` prints it. A caller that wants to
 * know whether anything was sent reads `sent`.
 */
import { type TelemetryEvent } from './event.js';
/** How many events one flush may send. */
export declare const MAX_BATCH = 500;
export interface FlushResult {
    /** How many events were accepted by the receiver. */
    readonly sent: number;
    /** Why nothing was sent, or null when something was. */
    readonly refused: string | null;
}
/**
 * Rebuilds an event from a stored line, or rejects it.
 *
 * A line that is missing a field is dropped rather than defaulted. A default
 * would invent a measurement -- a missing `library_version` filled in as the
 * running one attributes an old machine's numbers to this release -- and one
 * dropped line is cheaper than a wrong row.
 */
export declare function eventFromLine(line: string): TelemetryEvent | null;
/**
 * Everything on disk that is fit to send, oldest first.
 *
 * Asynchronous because nothing needs it synchronously -- both callers are async
 * -- and the recorder's sync writes are on the hot path where this is not.
 */
export declare function pendingEvents(env?: NodeJS.ProcessEnv): Promise<TelemetryEvent[]>;
/**
 * Sends what is pending, and clears the log only on success.
 *
 * CLEARING IS THE LAST THING IT DOES, and only when the receiver accepted. The
 * obvious order -- read, clear, send -- loses the batch on any failed request,
 * which is how a week of an intermittent connection becomes no data at all. The
 * cost of this order is a duplicate if the response is lost after the insert
 * lands, which the receiver can deduplicate and this cannot.
 */
export declare function flushBeacon(env?: NodeJS.ProcessEnv, fetchImpl?: typeof fetch): Promise<FlushResult>;
//# sourceMappingURL=beacon.d.ts.map