Async-logger-debug
Enqueue a debug-level record through the async logger. This is the convenience wrapper for log(Level::Debug, ...).
Interface
pub async fn[S] AsyncLogger::debug(
self : AsyncLogger[S],
message : String,
fields~ : Array[@bitlogger.Field] = [],
) -> Unit {}input
self : AsyncLogger[S]- Async logger that should receive the debug record.message : String- Debug message text.fields : Array[Field]- Optional structured fields added to the record.
output
Unit- No return value. The record is handled according to logger state and policy.
Explanation
Detailed rules explaining key parameters and behaviors
- This helper delegates to
log(Level::Debug, ..., fields=fields). - The record is still subject to min-level gating, patching, filtering, and overflow policy.
- This helper does not accept a per-call target override. It uses the logger's stored target unless the logger was derived earlier with
with_target(...)orchild(...). - Debug records are useful for development and targeted diagnostics.
- Use this helper when a named debug call is clearer than a raw
log(...)call.
How to Use
Here are some specific examples provided.
When Need Async Development Diagnostics
When intermediate async flow details should be visible during debugging:
logger.debug("loaded worker config")In this example, the call site communicates its intended diagnostic level directly.
When Attach Structured Debug Context
When a debug event should include extra fields:
logger.debug(
"dispatch start",
fields=[@bitlogger.field("job_id", "42")],
)In this example, the record carries structured context without needing the generic log(...) form.
Error Case
e.g.:
If the logger minimum level is above
Debug, the record is skipped before enqueue.If the logger is closed or overflow policy prevents acceptance, the write may not become a normal queued record.
Notes
Prefer this helper when the event is semantically debug-level.
Use
log(...)when the level must be chosen dynamically or one call needs a target override.