naloveyuki/BitLogger
1
0
Fork 0
mirror of https://github.com/Nanaloveyuki/BitLogger.git synced 2026-07-31 07:24:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

📝 clarify async filter derivation

Browse Source
This commit is contained in:
Nanaloveyuki
2026-06-14 11:46:40 +08:00
parent 11b49208b2
commit 685797783c
1 changed files with 8 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/api/async-logger-with-filter.md
+8 -3
View File
@@ -31,7 +31,7 @@ pub fn[S] AsyncLogger::with_filter(
#### output #### output
- `AsyncLogger[S]` - A new async logger that only enqueues matching records. - `AsyncLogger[S]` - A new async logger value that only enqueues matching records.
### Explanation ### Explanation
@@ -39,7 +39,8 @@ Detailed rules explaining key parameters and behaviors
- Filtering happens after record construction and patch application but before enqueue. - Filtering happens after record construction and patch application but before enqueue.
- Existing filter logic is preserved and combined with the new predicate using logical `and`. - Existing filter logic is preserved and combined with the new predicate using logical `and`.
- The original async logger is not mutated. - The returned logger is derived from `self`; the original async logger value is not mutated.
- Only the stored filter pipeline changes. Target, minimum level, queue configuration, and lifecycle/failure state stay on the same `AsyncLogger[S]` surface.
- Filtering avoids unnecessary queue pressure for records that should never be delivered. - Filtering avoids unnecessary queue pressure for records that should never be delivered.
- In the current direct async coverage, derived filters can compose target, level, and message predicates together while the original logger still accepts writes according to its previous filter state. - In the current direct async coverage, derived filters can compose target, level, and message predicates together while the original logger still accepts writes according to its previous filter state.
@@ -57,6 +58,8 @@ let logger = async_logger(console_sink(), target="service")
In this example, non-matching records are dropped before they reach the async queue. In this example, non-matching records are dropped before they reach the async queue.
And the returned async logger still keeps the same queue-facing API surface as the source logger.
#### When Combine Several Async Filter Rules #### When Combine Several Async Filter Rules
When filtering depends on multiple conditions: When filtering depends on multiple conditions:
@@ -82,4 +85,6 @@ e.g.:
2. Async filtering is especially useful when queue capacity should be reserved for high-value records. 2. Async filtering is especially useful when queue capacity should be reserved for high-value records.
3. Use a derived logger value when one branch should enforce extra filter rules and the base async logger should stay unchanged. 3. State helpers such as `pending_count()`, `dropped_count()`, `is_closed()`, and `has_failed()` remain available on the returned logger because the visible async logger surface is preserved.
4. Use a derived logger value when one branch should enforce extra filter rules and the base async logger should stay unchanged.