BitLogger/docs/api/async-logger-info.md

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

name	group	category	update-time	description	key-word
async-logger-info	api	async	20260512	Enqueue an info-level record through the async logger using the most common built-in severity shortcut.	async logger info public

Async-logger-info

Enqueue an info-level record through the async logger. This is the convenience wrapper for log(Level::Info, ...).

Interface

pub async fn[S] AsyncLogger::info(
  self : AsyncLogger[S],
  message : String,
  fields~ : Array[@bitlogger.Field] = [],
) -> Unit {}

input

• self : AsyncLogger[S] - Async logger that should receive the info record.
• message : String - Info 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::Info, ...).
• The record is still subject to min-level gating, patching, filtering, and overflow policy.
• Info is often the default operational logging level for async application events.
• Use this helper when explicit info intent is clearer than a raw log(...) call.

How to Use

Here are some specific examples provided.

When Need Normal Operational Async Events

When async code should report routine progress or lifecycle events:

await logger.info("worker started")

In this example, the event is expressed at the most common operational logging level.

When Add Structured Operational Metadata

When an info event should include stable structured detail:

await logger.info(
  "job queued",
  fields=[@bitlogger.field("queue", "sync")],
)

In this example, the record remains concise while still carrying useful metadata.

Error Case

e.g.:

• If the logger minimum level is above Info, 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

1. This is often the most common convenience method for normal async application events.

2. Use log(...) when the call site needs a dynamic level or target override.