From af9e4e853acf686c75e3c343dac6bfb659521892 Mon Sep 17 00:00:00 2001 From: Nanaloveyuki Date: Sun, 14 Jun 2026 09:31:19 +0800 Subject: [PATCH] :memo: clarify async close post-shutdown log split --- docs/api/async-logger-close.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/api/async-logger-close.md b/docs/api/async-logger-close.md index a790a09..f46ce0d 100644 --- a/docs/api/async-logger-close.md +++ b/docs/api/async-logger-close.md @@ -40,6 +40,8 @@ Detailed rules explaining key parameters and behaviors - This helper does not itself wait for the worker to finish. - `close(...)` also does not change `has_failed()` or `last_error()`; it is a closure primitive, not a failure reset API. - Because this is a low-level close primitive, it does not first run `wait_idle()` or apply the runtime-dependent fallback logic used by `shutdown()`. +- After closure, later log attempts do not add new pending or dropped counts, but backend behavior can still differ before the closed queue rejects the record. +- In the current direct coverage, compatibility runtimes short-circuit before patch-path work on late log attempts, while native-worker runtimes may still build and patch the record before the closed queue rejects it. ### How to Use @@ -70,6 +72,8 @@ e.g.: - If `clear=false`, pending records may still exist after closure until worker drain or later cleanup resolves them. +- If callers perform late log attempts after closure, backlog counters still stay unchanged, but patch-path side effects are runtime-dependent and should not be treated as a portable post-close contract. + - If callers need graceful waiting for drain completion, `shutdown()` is usually the better API. ### Notes