From 3a216a2ada33c0846d71b2183fc3f1555c3d7946 Mon Sep 17 00:00:00 2001 From: Nanaloveyuki Date: Sun, 14 Jun 2026 11:19:08 +0800 Subject: [PATCH] :memo: clarify async error helper routing --- docs/api/async-logger-error.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/api/async-logger-error.md b/docs/api/async-logger-error.md index bfcc03a..5cc8363 100644 --- a/docs/api/async-logger-error.md +++ b/docs/api/async-logger-error.md @@ -40,7 +40,7 @@ pub async fn[S] AsyncLogger::error( Detailed rules explaining key parameters and behaviors - This helper delegates to `log(Level::Error, ..., fields=fields)`. -- The record is still subject to patching, filtering, and overflow policy. +- The record is still subject to min-level gating, patching, filtering, and overflow policy. - This helper does not accept a per-call target override. It uses the logger's stored target unless the logger was derived earlier with `with_target(...)` or `child(...)`. - Error records represent the highest built-in severity in this logger API. - Use this helper when a named error call is clearer than a raw `log(...)` call. @@ -70,6 +70,10 @@ logger.error( In this example, the error record carries structured context without falling back to the generic `log(...)` form. +And any shared context already carried by the logger still participates ahead of these per-call fields when the record is built. + +The write still uses the logger's stored target because this shortcut does not take a one-off `target=` override. + ### Error Case e.g.: