Files
BitLogger/docs/api/build-application-async-logger.md
T
2026-06-14 01:04:11 +08:00

93 lines
3.6 KiB
Markdown

---
name: build-application-async-logger
group: api
category: facade
update-time: 20260614
description: Build the application-facing runtime-sink async logger alias from an AsyncLoggerBuildConfig through the sync-first async builder path.
key-word:
- application
- async
- facade
- public
---
## Build-application-async-logger
Build an `ApplicationAsyncLogger` from `AsyncLoggerBuildConfig`. This is the application-facing runtime-sink async alias returned through `build_async_logger(...)`.
### Interface
```moonbit
pub fn build_application_async_logger(
config : AsyncLoggerBuildConfig,
) -> ApplicationAsyncLogger {
```
#### input
- `config : AsyncLoggerBuildConfig` - Combined sync logger config and async queue/runtime config.
#### output
- `ApplicationAsyncLogger` - Application-facing async runtime logger.
### Explanation
Detailed rules explaining key parameters and behaviors
- This API delegates to `build_async_logger(...)` directly.
- That means the embedded `LoggerConfig` is built first through the normal synchronous config path before the outer async layer is applied.
- Any optional synchronous queue layer and runtime-sink controls chosen by `build_logger(config.logger)` remain active under the returned logger.
- Because the result is only the `ApplicationAsyncLogger` alias over `AsyncLogger[@bitlogger.RuntimeSink]`, this builder does not hide any async helpers or introduce a wrapper layer.
- The returned logger keeps the full async lifecycle and state helper surface directly, including helpers such as `run()`, `shutdown()`, `pending_count()`, `dropped_count()`, `state()`, `wait_idle()`, `has_failed()`, and `last_error()`.
- It also keeps the same failure/reset and runtime-dependent post-close behavior documented on the underlying runtime-sink async logger.
- Use this alias-oriented builder when application code wants the standard runtime-sink async shape without narrowing the public surface.
### How to Use
Here are some specific examples provided.
#### When Need Config-driven App Async Boot
When both sync sink shape and async queue policy are assembled as typed config:
```moonbit
let logger = build_application_async_logger(
AsyncLoggerBuildConfig::new(
logger=LoggerConfig::new(target="app.async"),
async_config=AsyncLoggerConfig::new(max_pending=8),
),
)
```
In this example, the app-facing async facade is built directly from typed config.
And any configured synchronous runtime sink controls remain available through the returned `RuntimeSink`-backed async logger.
#### When Need Async State Helpers Immediately After App Construction
When application code should keep the ordinary async helper surface directly:
```moonbit
let logger = build_application_async_logger(config)
ignore(logger.pending_count())
ignore(logger.state())
```
In this example, the application alias exposes async state helpers directly because no narrowing wrapper is added.
### Error Case
e.g.:
- If file output is selected on a backend without native file support, backend behavior still applies when the worker drains records.
- If the logger is never `run()`, enqueue behavior and lifecycle state still follow the normal async logger rules.
### Notes
1. This is a facade over the existing async runtime logger builder.
2. Use `parse_and_build_application_async_logger(...)` when starting from JSON text.
3. Use `build_application_text_async_logger(...)` instead when callers should keep the concrete text-console sink type and the direct text-builder path.
4. Use `build_library_async_logger(...)` instead when a library boundary should narrow the exposed async surface.