naloveyuki/BitLogger
1
0
Fork 0
mirror of https://github.com/Nanaloveyuki/BitLogger.git synced 2026-07-30 06:26:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

📝 consolidate logger API and async lifecycle guidance

Browse Source
This commit is contained in:
Nanaloveyuki
2026-06-14 14:00:00 +08:00
parent 4f2ad097af
commit 265cd69ea9
154 changed files with 2419 additions and 396 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/api/library-async-logger-info.md
+16 -6
View File
@@ -2,8 +2,8 @@
name: library-async-logger-info
group: api
category: facade
update-time: 20260613
description: Enqueue an info-level record through a LibraryAsyncLogger facade using the informational severity shortcut.
update-time: 20260614
description: Enqueue an info-level record through a LibraryAsyncLogger facade by delegating to the wrapped async logger's info shortcut.
key-word:
- async
- library
@@ -39,10 +39,12 @@ pub async fn[S] LibraryAsyncLogger::info(
Detailed rules explaining key parameters and behaviors
- This helper delegates to `log(Level::Info, ...)` on the wrapped async logger.
- The record is still subject to min-level gating, patching, filtering, and overflow policy.
- This helper delegates to `info(...)` on the wrapped async logger, which in turn uses `log(Level::Info, ...)`.
- The record is still subject to min-level gating, stored shared context fields, patching, filtering, and overflow policy.
- This helper does not accept a per-call target override. It uses the facade's stored target unless the facade was derived earlier with `with_target(...)` or `child(...)`.
- `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.
- Async state helpers remain on the underlying `AsyncLogger[S]` and require `to_async_logger()` first.
### How to Use
@@ -52,7 +54,7 @@ Here are some specific examples provided.
When async package code should report routine progress or lifecycle events:
```moonbit
await logger.info("worker started")
logger.info("worker started")
```
In this example, the event is expressed at the common operational logging level through the narrower facade.
@@ -61,7 +63,7 @@ In this example, the event is expressed at the common operational logging level
When an info event should include stable structured detail:
```moonbit
await logger.info(
logger.info(
"job queued",
fields=[@bitlogger.field("queue", "sync")],
)
@@ -69,6 +71,10 @@ await logger.info(
In this example, the record remains concise while still carrying useful metadata.
And any shared context fields already stored on the facade are still prepended before these per-call fields.
And the write still uses the facade's stored target because this shortcut does not take a one-off `target=` override.
### Error Case
e.g.:
@@ -76,8 +82,12 @@ e.g.:
- If the logger is closed or overflow policy prevents acceptance, the write may not become a normal queued record.
- If callers need a per-call target override, they should use `log(...)` instead of this fixed-level shortcut.
### Notes
1. This is often the most common convenience method for normal async library events.
2. Use `log(...)` when the call site needs a dynamic level or target override.
3. Use `to_async_logger()` first when later code needs queue or failure inspection rather than another write shortcut.