Skip to content

fix: apply the documented WARNING log level default in docling-serve run - #708

Open
Ulli2060 wants to merge 1 commit into
docling-project:mainfrom
Ulli2060:fix/log-level-single-default
Open

Ulli2060 wants to merge 1 commit into
docling-project:mainfrom
Ulli2060:fix/log-level-single-default

Conversation

@Ulli2060

Copy link
Copy Markdown
Contributor

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 #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.

Change: the settings field becomes log_level: LogLevel = LogLevel.WARNING, the CLI writes -v/-vv into 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 through DOCLING_SERVE_LOG_LEVEL, like the other CLI options since #686.

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 /health 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; happy to switch if you prefer that.

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 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): run without -v leaves the settings, the root logger and uvicorn.access at WARNING; -v raises them to INFO; -vv reaches the reload subprocess; the default is exported explicitly; DOCLING_SERVE_LOG_LEVEL=debug is honored unless -v overrides it; an empty DOCLING_SERVE_LOG_LEVEL selects the default; a single-process run leaves the environment alone. The fixture now gives each test its own copy of os.environ, since _run writes 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.

`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>
@github-actions

Copy link
Copy Markdown
Contributor

DCO Check Passed

Thanks @Ulli2060, all your commits are properly signed off. 🎉

@mergify

mergify Bot commented Sep 21, 2026

Copy link
Copy Markdown
Contributor

Merge Protections

🟢 Merge protection satisfied — ready to merge.

Show 1 satisfied protection

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

  • title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

@Ulli2060
Ulli2060 marked this pull request as ready for review September 21, 2026 10:25

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant