Conversation
`docling-serve run` without `-v` and without DOCLING_SERVE_LOG_LEVEL logs at INFO although docs/configuration.md promises WARNING and the rq worker already defaults to WARNING. The CLI callback did apply WARNING, but uvicorn imports `docling_serve.app` afterwards, and that module configured logging again at import time with an INFO fallback of its own, overriding the CLI's choice. This dates from docling-project#617 (v1.21.0), which replaced the no-op `basicConfig(INFO)` in app.py with `setup_logging(...)`, a call that replaces the root handlers and level. Make the settings field non-optional with WARNING as its default, let the CLI write `-v`/`-vv` into it, and have the app module and the rq worker read that field without a fallback. With reload or multiple workers the level is handed to the spawned process through DOCLING_SERVE_LOG_LEVEL, like the other CLI options since docling-project#686. An empty DOCLING_SERVE_LOG_LEVEL (which `env_parse_none_str` turns into None, common in container templates) keeps meaning "not set": the field validator maps it to the field's default instead of failing validation. Behaviour change: a deployment that starts `docling-serve run` or `docling-serve dev` with none of `-v`, `-vv` or DOCLING_SERVE_LOG_LEVEL set (the container image's default command is `run`) now logs at WARNING instead of INFO. Because setup_logging pins the uvicorn loggers to the same level, uvicorn's access log goes quiet at the default as well, and so does the INFO line the /health endpoint writes on every probe. Set DOCLING_SERVE_LOG_LEVEL=INFO or pass `-v` to keep the previous output. `docling-serve rq-worker -v` now honors `-v` too; the worker used to re-apply the settings-only level and drop the flag. The default lives in one place (DoclingServeSettings.log_level): should INFO be the preferred effective default instead, that value and the docs row are the only things to change. Signed-off-by: Markus Uhlending <privat0816@gmail.com>
Contributor
|
✅ DCO Check Passed Thanks @Ulli2060, all your commits are properly signed off. 🎉 |
Contributor
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
Ulli2060
marked this pull request as ready for review
September 21, 2026 10:25
This branch has not been deployed
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.
docling-serve runwithout-vand withoutDOCLING_SERVE_LOG_LEVELlogs at INFO althoughdocs/configuration.mdpromises WARNING and the rq worker already defaults to WARNING. The CLI callback did apply WARNING, but uvicorn importsdocling_serve.appafterwards, and that module configured logging again at import time with an INFO fallback of its own, overriding the CLI's choice. This dates from #617 (v1.21.0), which replaced the no-opbasicConfig(INFO)inapp.pywithsetup_logging(...), a call that replaces the root handlers and level.Change: the settings field becomes
log_level: LogLevel = LogLevel.WARNING, the CLI writes-v/-vvinto it, and the app module and the rq worker read that field without a fallback of their own. With reload or multiple workers the level is handed to the spawned process throughDOCLING_SERVE_LOG_LEVEL, like the other CLI options since #686.Behaviour change: a deployment that starts
docling-serve runordocling-serve devwith none of-v,-vvorDOCLING_SERVE_LOG_LEVELset (the container image's default command isrun) now logs at WARNING instead of INFO. Becausesetup_loggingpins the uvicorn loggers to the same level, uvicorn's access log goes quiet at the default as well, and so does the INFO line/healthwrites on every probe. SetDOCLING_SERVE_LOG_LEVEL=INFOor pass-vto keep the previous output.docling-serve rq-worker -vnow honors-vtoo; the worker used to re-apply the settings-only level and drop the flag.The default lives in one place (
DoclingServeSettings.log_level). Should INFO be the preferred effective default instead, that value and the docs row are the only things to change; happy to switch if you prefer that.An empty
DOCLING_SERVE_LOG_LEVEL=""(whichenv_parse_none_strturns intoNone, common in container templates) keeps meaning "not set": the field validator maps it to the field's own default (read from the field, so the default is declared once) instead of failing validation now that the field is not optional.Tests (
tests/test_cli_subprocess_settings.py):runwithout-vleaves the settings, the root logger anduvicorn.accessat WARNING;-vraises them to INFO;-vvreaches the reload subprocess; the default is exported explicitly;DOCLING_SERVE_LOG_LEVEL=debugis honored unless-voverrides it; an emptyDOCLING_SERVE_LOG_LEVELselects the default; a single-process run leaves the environment alone. The fixture now gives each test its own copy ofos.environ, since_runwrites the hand-over variables directly.AI disclosure
The change and its tests were prepared with an AI coding assistant (Claude Code) under my direction; I reviewed the code paths against v1.34.0 and ran the tests, ruff and mypy locally.