From e386ef8b28e3e1f6c7164a5a8346a017ecc51eaf Mon Sep 17 00:00:00 2001 From: Nanaloveyuki Date: Sun, 14 Jun 2026 09:33:24 +0800 Subject: [PATCH] :memo: clarify library async run restart semantics --- docs/api/library-async-logger-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/api/library-async-logger-run.md b/docs/api/library-async-logger-run.md index 90a9016..93c83c0 100644 --- a/docs/api/library-async-logger-run.md +++ b/docs/api/library-async-logger-run.md @@ -36,6 +36,7 @@ Detailed rules explaining key parameters and behaviors - This method delegates directly to the wrapped async logger's `run()` behavior. - 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. +- Once a delegated `run()` call has actually started, it clears any previous `has_failed()` flag and stored `last_error()` string on that same wrapped logger before draining resumes. - 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. - Unwrapping after a delegated `run()` exposes the same failure and backlog state that accumulated behind the facade; it does not create a second runtime view. @@ -76,6 +77,8 @@ e.g.: - If `run()` is never started, accepted records may remain queued and not reach the sink. +- A later delegated `run()` attempt starts from a fresh failure flag and empty `last_error()` string on the same wrapped logger, even if an earlier facade-level run failed. + - If callers need to inspect `is_running()`, `has_failed()`, or `last_error()` directly, they must unwrap first with `to_async_logger()`. ### Notes