Async-logger-is-running

Read whether the async logger worker is currently active. This helper is useful for runtime diagnostics and shutdown coordination.

Interface

pub fn[S] AsyncLogger::is_running(self : AsyncLogger[S]) -> Bool {}

input

• self : AsyncLogger[S] - Async logger whose worker state should be inspected.

output

• Bool - Whether the async worker loop is currently running.

Explanation

Detailed rules explaining key parameters and behaviors

• run() sets the running state while the worker loop is active.
• The flag is cleared when the worker exits normally or after failure handling finishes.
• A logger may be closed while still running briefly during final drain or shutdown processing.
• After a worker failure, the logger can already be is_running=false while still retaining has_failed=true, the recorded last_error(), and leftover dropped-count cleanup.
• This helper is derived from the current lifecycle phase rather than from an independent running flag ref; it does not wait, synchronize, or infer why the value is what it is.
• This helper focuses on worker activity rather than queue size or failure details.
• is_running() can be false even when pending_count() is still nonzero, for example if the worker was never started or if it exited after a recorded failure.
• A later run() attempt can flip is_running() back to true before that retained failure/backlog state has been fully drained, because the restarted worker clears stale failure state only once the new run has actually started.

How to Use

Here are some specific examples provided.

When Need Worker Activity Diagnostics

When runtime output should show whether the worker loop is active:

println(logger.is_running().to_string())

In this example, diagnostics can distinguish an idle configured logger from one with an active worker.

When Coordinate Shutdown Waiting

When code should poll worker completion explicitly:

while logger.is_running() {
  @async.pause()
}

In this example, callers watch the worker lifecycle directly.

Error Case

e.g.:

• If is_running() is false, pending records may still exist if the worker was never started or has already failed.

• If is_running() is false, the logger may also already be closed while still retaining the previous failure record and the cleanup result from shutdown.

• If callers need a one-shot lifecycle flow, shutdown() is usually better than manual polling.

• If is_running() is true, that still does not guarantee healthy drain progress; callers may need has_failed() or state() for failure context.

• Under concurrent activity, the returned value may change immediately after it is read.

Notes

1. Use this helper for worker activity checks, not as a complete health signal.

2. Pair it with has_failed() or state() when diagnosing stalled pipelines.

3. Pair it with pending_count() when you need to distinguish an idle worker from a stopped logger that still has backlog.