diff --git a/docs/api/library-async-logger-is-enabled.md b/docs/api/library-async-logger-is-enabled.md index 089d49f..87cdca7 100644 --- a/docs/api/library-async-logger-is-enabled.md +++ b/docs/api/library-async-logger-is-enabled.md @@ -3,7 +3,7 @@ name: library-async-logger-is-enabled group: api category: facade update-time: 20260614 -description: Check whether a LibraryAsyncLogger facade would accept a record at a given level before using the repo's direct async call style. +description: Check whether a LibraryAsyncLogger facade passes the wrapped async logger's min-level gate for a given severity. key-word: - async - library @@ -38,8 +38,9 @@ pub fn[S] LibraryAsyncLogger::is_enabled( Detailed rules explaining key parameters and behaviors - This method delegates directly to the wrapped async logger's `is_enabled(...)` behavior. -- It only checks logger-level severity gating; it does not evaluate later filter or overflow behavior. -- The result reflects the current facade value, so derived facades with different thresholds can return different answers. +- It only checks logger-level severity gating through `min_level`; it does not evaluate later filter, patch, closed-on-log, or overflow behavior. +- The result reflects the current wrapped logger state, so derived facades with different thresholds can return different answers. +- This check does not require unwrapping because it is part of the narrower library-facing surface. - Use it when message construction or field gathering is expensive enough to justify a pre-check. ### How to Use @@ -68,6 +69,8 @@ if logger.is_enabled(@bitlogger.Level::Warn) { In this example, the check mirrors the same severity gate used by later async write calls. +And a `true` result still means only that the level gate passed, not that the record is guaranteed to reach the sink. + ### Error Case e.g.: @@ -75,8 +78,12 @@ e.g.: - A `true` result does not guarantee final delivery if later queue or filter behavior rejects the record. +- If callers need to inspect queue or failure state instead of only checking the level gate, they must unwrap first with `to_async_logger()`. + ### Notes 1. This is a cheap severity check, not a full end-to-end delivery guarantee. 2. Prefer using it only when precomputing the async log payload is meaningfully expensive. + +3. Use `log(...)` or the severity shortcuts directly when no expensive precomputation needs to be avoided. diff --git a/docs/api/library-async-logger-run.md b/docs/api/library-async-logger-run.md index 6ea00a2..74eadc7 100644 --- a/docs/api/library-async-logger-run.md +++ b/docs/api/library-async-logger-run.md @@ -3,7 +3,7 @@ name: library-async-logger-run group: api category: facade update-time: 20260613 -description: Start the LibraryAsyncLogger worker loop so queued records are drained to the underlying sink. +description: Start the LibraryAsyncLogger worker loop by delegating to the wrapped async logger's run behavior. key-word: - async - library @@ -37,6 +37,7 @@ Detailed rules explaining key parameters and behaviors - It starts the worker loop that makes accepted queued records reach the underlying sink. - Failure and lifecycle state are still tracked by the wrapped async logger. - The narrower library facade does not hide the need to explicitly activate queue draining. +- If the worker fails, the wrapped async logger records that through its failure-state helpers, which still require `to_async_logger()` for inspection from library-facing code. ### How to Use @@ -65,6 +66,8 @@ group.spawn_bg(() => logger.run()) In this example, the caller decides when the worker begins instead of hiding that lifecycle step. +And the started worker loop is still the same wrapped async logger runtime rather than a separate library-specific execution path. + ### Error Case e.g.: @@ -72,8 +75,12 @@ e.g.: - If `run()` is never started, accepted records may remain queued and not reach the sink. +- If callers need to inspect `is_running()`, `has_failed()`, or `last_error()` directly, they must unwrap first with `to_async_logger()`. + ### Notes 1. `LibraryAsyncLogger::new(...)` only constructs the facade; `run()` is what activates queue draining. 2. Pair this API with `shutdown()` for a complete worker lifecycle. + +3. Use `to_async_logger()` first when operational code needs direct lifecycle or failure inspection in addition to starting the worker. diff --git a/docs/api/library-async-logger-shutdown.md b/docs/api/library-async-logger-shutdown.md index 16f66c2..66933e0 100644 --- a/docs/api/library-async-logger-shutdown.md +++ b/docs/api/library-async-logger-shutdown.md @@ -3,7 +3,7 @@ name: library-async-logger-shutdown group: api category: facade update-time: 20260614 -description: Gracefully stop a LibraryAsyncLogger by draining or clearing queued work, with worker-wait behavior depending on the active async runtime. +description: Gracefully stop a LibraryAsyncLogger by delegating to the wrapped async logger's shutdown behavior, including runtime-dependent drain and worker-wait rules. key-word: - async - library @@ -42,6 +42,7 @@ Detailed rules explaining key parameters and behaviors - If the active async runtime uses shutdown clearing after idle and backlog still remains, the wrapped logger falls back to `close(clear=true)`. - `clear=true` immediately closes and abandons pending records. - In runtimes where shutdown waits for workers, the method then waits until the worker is no longer running before returning. +- The narrower library facade does not change any of these runtime-dependent shutdown rules; it only keeps the broader inspection helpers out of the direct public surface. ### How to Use @@ -65,6 +66,8 @@ logger.shutdown(clear=true) In this example, pending work is abandoned intentionally so shutdown can complete sooner. +And the decision still applies to the same wrapped async logger state rather than a separate library-specific queue. + ### Error Case e.g.: @@ -74,6 +77,8 @@ e.g.: - If callers skip `shutdown()` and only inspect flags manually, it is easier to leave the worker lifecycle in an unclear state. +- If callers need to inspect `pending_count()`, `dropped_count()`, `is_running()`, or failure state during shutdown analysis, they must unwrap first with `to_async_logger()`. + ### Notes 1. Prefer this API over low-level closure control in normal library shutdown paths. @@ -81,3 +86,5 @@ e.g.: 2. Exact post-close waiting behavior depends on the active async runtime mode. 3. Choose `clear=true` only when loss of queued records is acceptable. + +4. Use `to_async_logger()` first when shutdown orchestration also needs direct lifecycle or backlog inspection.