fix(asr): log active audio filename in AsrPipeline._build_document

[charlesaurav13]

Summary

When converting a batch (e.g. a directory of audio files with docling /path/to/dir), only a single Going to convert document batch... log entry appeared for the entire batch, with no indication of which file was being processed.

This made it impossible to track progress or identify which file was currently active — especially confusing for long audio transcriptions.

Fix: add a per-document info log at the start of _execute_pipeline. This fires for both sequential and concurrent conversion paths and is consistent with the existing Finished converting document X in Y sec. log that follows it.

INFO  Starting conversion of document lecture_01.mp3.
INFO  Finished converting document lecture_01.mp3 in 12.45 sec.
INFO  Starting conversion of document lecture_02.mp3.
...

Reproduction

docling /path/to/directory/with/multiple/audio/files

Previously only showed Going to convert document batch... with no per-file progress.

Related issue

Closes #3467

[github-actions]

✅ DCO Check Passed

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

[mergify]

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)(?:\(.+\))?(!)?:

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cau-git]

@charlesaurav13 thanks for the proposal, but I think the fix is not complete since it will then duplicate the logging for PDF files for example, which already happens in the particular pipeline, such as:
docling.pipeline.base_pipeline: Processing document right_to_left_03.pdf

Either you move this log into the simple pipeline / audio backend or we must remove logs on the other pipelines.

Please also apply the linting (make check, make validate-all) and clear the DCO check, so the tests pass. Thanks.

[cau-git]

changes required as outlined above.

[charlesaurav13]

Good catch — adding the log at _execute_pipeline level fires for all document types, duplicating the Processing document X line that already exists in the standard PDF/base pipeline.

The right scope is the ASR pipeline specifically (where no equivalent log currently exists). I'll update this PR to move the log into AsrPipeline instead of DocumentConverter._execute_pipeline, so it only fires for audio files.

Will also clear the DCO and run make check / make validate-all before pushing.

[charlesaurav13]

Updated. The change is now scoped to AsrPipeline._build_document only:

• Reverted the _execute_pipeline change in DocumentConverter (which fired for all formats).
• Changed the existing log in _build_document from the internal 'start _build_document in AsrPipeline: <full_path>' to 'Transcribing audio document <filename>.' — user-facing wording using just the filename for consistency with other pipeline logs.

This means the log fires only for audio files, with no duplication. DCO signed off with -s.

[PeterStaar-IBM]

@charlesaurav13 Can you do the DCO? see here: #3535 (comment)

[ceberam]

Good catch!

And I also like the slight improvement of using %s instead of the f-string for logging messages.

[charlesaurav13]

Added the DCO remediation commit with the exact hash (586...........). Should be clear now.