Repository navigation
Write structlog lines through a plain StreamHandler and remove logging_buffer_capacity and logging_flush_level - #378
Merged
Merged
Conversation
…g_buffer_capacity and logging_flush_level
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #377.
MemoryLoggerFactorynow attaches itsStreamHandlerto each structlog stdlib logger directly, with noMemoryHandlerin front of it.logging_buffer_capacityandlogging_flush_levelare removed fromLoggingConfigand from_MemoryLoggerFactoryConfig.The issue and its comment have the reasoning and the sources. In short,
MemoryHandler.flush()hands buffered records to the target one at a time, so every line still got its own write and flush. On Linux the buffer made each line 0.2 to 0.3 µs slower, and it wrote structlog lines out of order with stdlib lines, held them back until ten built up or an ERROR arrived, and lost them on a hard exit.close_handlersremoves and closes theStreamHandler.StreamHandler.close()leaves the stream open, as before.MemoryLoggerFactory,_MemoryLoggerFactoryConfigandmemory_logger_factory, although nothing is buffered in memory now.MemoryLoggerFactoryis a public export, and a rename belongs in its own change, throughdeprecated_module_getattr.Tests
Written first.
test_structlog_lines_are_written_at_once_and_in_order_with_stdlib_linesbootstrapsLoggingInstrumentwith the default config and logs structlog "1", stdlib "2", structlog "3". Before teardown, main had written only['2']. It now reads['1', '2', '3'].test_memory_logger_factory_writes_each_line_at_oncereplacestest_memory_logger_factory_infoandtest_memory_logger_factory_error, which asserted the buffering this removes. It checks that each INFO line is on the stream as soon as it is logged, and that the logger's only handler is aStreamHandler.test_litestar_bootstrap.pyandtest_faststream_bootstrap.pyexpectStreamHandlernow.logging_buffer_capacity=0is gone from the tests and fromscripts/floor_smoke.pyandscripts/ft_smoke.py. Those tests set it only to switch the buffer off.The full suite passes, 591 tests at 100% coverage (
just test-ci).just lint(includingty),just adr-checkandjust docs-buildpass too.scripts/floor_smoke.pypasses locally for all five targets. I couldn't runscripts/ft_smoke.pyhere, because it needs a free-threaded interpreter. No floor changes.Docs
configuration.mdno longer lists the two fields. The FastStream and FastMCP examples no longer passlogging_buffer_capacity=0.benchmarks/frameworks/logging_suite.pyloses theinfo_capacity1scenario. Inbenchmarks/README.md§8f thelogging_buffer_capacity=1row is gone. The chain description still namesMemoryHandler(capacity=10), because that is what the rows measured, and a new note says it has since been removed and the rows have not been rerun.Breaking changes
logging_buffer_capacityorlogging_flush_levelto a config raisesTypeError.from_dictandfrom_objectignore keys they don't know, so settings loaded through them keep working.StreamHandler, not aMemoryHandler.