diff --git a/docs/api/application-async-logger.md b/docs/api/application-async-logger.md index 98e9f17..ae2ccb6 100644 --- a/docs/api/application-async-logger.md +++ b/docs/api/application-async-logger.md @@ -33,6 +33,7 @@ Detailed rules explaining key parameters and behaviors - It preserves the same async lifecycle helpers such as `run()`, `shutdown()`, `pending_count()`, and `state()`. - Because it is `AsyncLogger[@bitlogger.RuntimeSink]`, the alias also keeps ordinary async logger composition and target behavior such as `with_target(...)`, `child(...)`, and per-call `log(..., target=...)` overrides. - In particular, `log(..., target=...)` can override the target for one call, while severity helpers such as `info(...)`, `warn(...)`, and `error(...)` continue using the stored logger target unless code derives another logger first with `with_target(...)` or `child(...)`. +- Unlike the synchronous application alias, async `with_context_fields(...)` and `bind(...)` preserve the visible `ApplicationAsyncLogger` shape because shared fields are stored directly on the async logger value instead of being modeled as a separate sink wrapper. - Because this is only an alias, methods that are async on `AsyncLogger[@bitlogger.RuntimeSink]` remain async here as well. - The alias therefore keeps the same runtime-sink lifecycle, queue, failure-state, and runtime-dependent post-close semantics already documented on `AsyncLogger[@bitlogger.RuntimeSink]`. - In the current direct alias coverage, values built through `build_application_async_logger(...)` keep the same serialized state snapshot shape, queue counters, lifecycle flags, failure fields, and runtime-sink helper surface that the underlying runtime-sink async logger exposes directly. @@ -79,6 +80,17 @@ In this example, the emitted record uses `app.async.audit` only for that one cal And later `info(...)`, `warn(...)`, or `error(...)` calls still use the alias value's stored target unless code derives another logger first with `with_target(...)` or `child(...)`. +#### When Need Shared Context On The Async Application Alias + +When app-level async code should attach stable metadata to later queued records: +```moonbit +let contextual = logger.with_context_fields([@bitlogger.field("service", "billing")]) +``` + +In this example, the returned value still has the visible type `ApplicationAsyncLogger`. + +And that shape preservation is intentional because async context binding updates stored logger metadata instead of changing the exposed sink type. + ### Error Case e.g.: diff --git a/docs/api/application-logger.md b/docs/api/application-logger.md index 007909b..10bb754 100644 --- a/docs/api/application-logger.md +++ b/docs/api/application-logger.md @@ -33,6 +33,7 @@ Detailed rules explaining key parameters and behaviors - It preserves the same logging, queue, and file helper APIs exposed by `ConfiguredLogger`. - Because `ConfiguredLogger` is itself `Logger[RuntimeSink]`, the alias also keeps ordinary logger composition and write behavior such as `with_target(...)`, `child(...)`, and `log(..., target=...)`. - In particular, `log(..., target=...)` can override the target for one call, while severity helpers such as `info(...)`, `warn(...)`, and `error(...)` continue using the stored logger target unless code derives another logger first with `with_target(...)` or `child(...)`. +- Like the underlying synchronous logger line, `with_context_fields(...)` and `bind(...)` do not preserve the alias spelling. They return a `Logger[ContextSink[RuntimeSink]]` shape because sync shared-field binding extends the sink pipeline instead of storing extra alias-level context metadata. - Because this is only an alias, the application-facing type does not hide any configured-runtime helpers or broader logger surface. - The alias exists to give application boot code a clearer public entry name. - Builders such as `build_application_logger(...)` and `parse_and_build_application_logger(...)` return this alias. @@ -76,6 +77,17 @@ In this example, the emitted record uses `app.audit` only for that one call. And later `info(...)`, `warn(...)`, or `error(...)` calls still use the alias value's stored target unless code derives another logger first with `with_target(...)` or `child(...)`. +#### When Need Shared Context On The Sync Application Alias + +When app-level sync code should attach stable metadata to later records: +```moonbit +let contextual = logger.with_context_fields([field("service", "billing")]) +``` + +In this example, the returned value has the visible type `Logger[ContextSink[RuntimeSink]]` rather than the alias name `ApplicationLogger`. + +And that type-shape change is expected because sync context binding extends the sink pipeline. + ### Error Case e.g.: diff --git a/docs/api/application-text-async-logger.md b/docs/api/application-text-async-logger.md index 4a22b60..3bea964 100644 --- a/docs/api/application-text-async-logger.md +++ b/docs/api/application-text-async-logger.md @@ -33,6 +33,7 @@ Detailed rules explaining key parameters and behaviors - It preserves the same async lifecycle helpers as other async logger aliases. - Because it is `AsyncLogger[@bitlogger.FormattedConsoleSink]`, the alias also keeps ordinary async logger composition and target behavior such as `with_target(...)`, `child(...)`, and per-call `log(..., target=...)` overrides. - In particular, `log(..., target=...)` can override the target for one call, while severity helpers such as `info(...)`, `warn(...)`, and `error(...)` continue using the stored logger target unless code derives another logger first with `with_target(...)` or `child(...)`. +- Like the broader runtime-sink async alias, `with_context_fields(...)` and `bind(...)` preserve the visible `ApplicationTextAsyncLogger` shape because shared fields are stored directly on the async logger value instead of being modeled as a separate sink wrapper. - Because this is only an alias, methods that are async on `AsyncLogger[@bitlogger.FormattedConsoleSink]` remain async here as well. - The alias therefore keeps the same text-console-specific builder and lifecycle semantics already documented on `AsyncLogger[@bitlogger.FormattedConsoleSink]`, including the concrete sink shape plus the same close, queue, and failure-state behavior. - The application-facing type does not hide any async state or lifecycle helpers; queue/backlog/failure inspection remains directly available on this alias just as it is on the underlying `AsyncLogger[@bitlogger.FormattedConsoleSink]`. @@ -83,6 +84,17 @@ In this example, the emitted record uses `app.text.async.audit` only for that on And later `info(...)`, `warn(...)`, or `error(...)` calls still use the alias value's stored target unless code derives another logger first with `with_target(...)` or `child(...)`. +#### When Need Shared Context On The Text-console Async Alias + +When app-level text-console async code should attach stable metadata to later queued records: +```moonbit +let contextual = logger.with_context_fields([@bitlogger.field("service", "billing")]) +``` + +In this example, the returned value still has the visible type `ApplicationTextAsyncLogger`. + +And that shape preservation is intentional because async context binding updates stored logger metadata instead of changing the exposed sink type. + ### Error Case e.g.: