BitLogger/docs/api/configured-logger-pending-count.md

name, group, category, update-time, description, key-word

name	group	category	update-time	description	key-word
configured-logger-pending-count	api	runtime	20260512	Read the current queued backlog count from a configured runtime logger.	logger runtime queue public

Configured-logger-pending-count

Read the current queued backlog count from a ConfiguredLogger. This is the direct runtime metric for config-driven queue wrapping.

Interface

pub fn ConfiguredLogger::pending_count(self : ConfiguredLogger) -> Int {}

input

• self : ConfiguredLogger - Config-driven runtime logger whose queue backlog should be inspected.

output

• Int - Current number of pending queued records.

Explanation

Detailed rules explaining key parameters and behaviors

• Queue-backed sinks return their live pending count.
• Non-queued sinks report 0.
• This is a point-in-time metric and may change immediately after it is read.
• This helper delegates to RuntimeSink::pending_count(...) through the configured logger wrapper.

How to Use

Here are some specific examples provided.

When Need Configured Queue Backlog Visibility

When a config-built logger should expose queue pressure:

let pending = logger.pending_count()

In this example, queue backlog is observed without reaching into the sink internals.

When Verify Manual Drain Progress

When drain loops should observe remaining backlog:

ignore(logger.drain(max_items=8))
ignore(logger.pending_count())

In this example, the queue metric helps verify manual drain progress.

Error Case

e.g.:

• If the logger is not queue-backed, the method simply returns 0.

• If callers need richer file-plus-queue state for file sinks, file_runtime_state() is the better API.

Notes

1. Use this helper for simple queue visibility on config-built loggers.

2. Pair it with dropped_count() when investigating loss behavior.