microsoft.opentelemetry.a365.core.exporters.replay_coordinator module

Background replay coordinator for durable telemetry delivery.

class microsoft.opentelemetry.a365.core.exporters.replay_coordinator.ReplayCoordinator(storage, gate, send, poll_interval_seconds=30.0)[source]

Bases: object

Drive durable record replay on a single daemon thread.

start()[source]

Start the replay loop on one daemon thread.

Calling start() after shutdown() is a deliberate safe no-op: once the stop event has been set the coordinator is permanently stopped and a new instance should be created instead.

Return type:

None

wake()[source]

Wake the replay thread to run another pass.

Return type:

None

shutdown(timeout_seconds=None)[source]

Signal the replay thread to stop and wait for it to exit.

timeout_seconds=None (the default) waits indefinitely: the caller decides how long “long enough” is, so this primitive never silently gives up and reports success while the thread is still running a pass. A finite value performs a bounded wait instead and returns whether the thread had exited by the deadline; the stop request itself is always recorded regardless of the timeout, so a later bounded or unbounded call will still observe (and can wait out) the same in-progress shutdown.

Safe to call concurrently from multiple threads. A thread can never join itself, so a call made from the replay thread itself (e.g. via an unexpected reentrant callback) returns False immediately without blocking or raising – the stop request is still recorded, but the caller cannot safely wait here for its own thread to exit.

Return type:

bool

run_once()[source]

Claim and process a single bounded replay batch.

Returns True only when a maximal batch (_MAX_RECORDS_PER_PASS) was claimed and every record in it reached a terminal state (delivered or permanently dropped). In that case more records may remain and the loop should run again immediately. It returns False for an empty/partial batch, when the pass was stopped early (retryable failure, shutdown, or unexpected error), or when any record was left behind (gate-blocked or released), so the loop falls back to the periodic cadence and does not busy-spin.

Return type:

bool

exception microsoft.opentelemetry.a365.core.exporters.replay_coordinator.ReplayEndpointError[source]

Bases: Exception

Raised when replay cannot safely use the current exporter endpoint.

Task 2 raises this from the replay send callback when the reconstructed endpoint is invalid for bearer-token replay (for example, non-HTTPS). Task 3 will add coordinator-specific handling.

exception microsoft.opentelemetry.a365.core.exporters.replay_coordinator.ReplayIdentityError[source]

Bases: Exception

Raised by the send callback when an identity or token cannot be resolved.

When the coordinator catches this exception, it releases the current record and releases the gate probe for that identity, then continues processing remaining records in the batch. This is appropriate for transient, per-identity failures (e.g. credential look-up errors) that should not block delivery of records belonging to other identities.

Contrast with unexpected / general exceptions, which cause the coordinator to release all remaining leased records and abort the current pass.