Providing Runtime Page Ranges for DoclingConverter in a Pipeline

[ganny-gitaa]

If I wish to have a pipeline which processes PDF files, I know I can instantiate a DoclingConverter component and provide page ranges I wish to processes via the convert_kwargs parameter. This is fine, if I am processing just a single file whose page ranges are a priory known.

But what should I do if I have a bunch of files, each with their own page ranges which I only get to know at the time of pipeline execution? I understand that haystack allows one to provide runtime parameters when the pipeline is executed which can be used by the run method of the various components. Unfortunately I cannot pass convert_kwargs since it's only a parameter used to instantiate the DoclingConverter component and not exposed by the run method of the component.

Surprisingly enough upon inspection of the source the convert_kwargs are only ever used within the run method of the DoclingConverter. Is there some solution which I am missing or should I write my own CustomDoclingConverter to realize this?

[yudin-s]

Your reading is right: this is not a good fit for normal Pipeline runtime parameters as-is.

Haystack runtime parameters can only be passed to inputs that a component exposes through its run() signature. DoclingConverter exposes convert_kwargs as constructor/configuration state, while run() is the conversion call. So if each source needs a different page_range, there is no clean built-in way to pass a per-file convert_kwargs map into one shared DoclingConverter instance at pipeline execution time.

The options I would consider are:

1. If files can be grouped by the same page range, create one converter per group with that group's convert_kwargs.
2. If every file has its own range, run the converter outside the Pipeline loop per file, constructing/calling it with that file's kwargs.
3. For a reusable Pipeline component, write a small wrapper/custom component with a run() signature like sources plus page_ranges or convert_kwargs_by_source. Inside that wrapper, call DoclingConverter once per source with the merged kwargs and return the combined documents.

I would avoid mutating one converter instance's convert_kwargs immediately before each call inside a shared Pipeline, especially if the pipeline might run concurrently or be reused. A wrapper component is the safer shape because the per-file page range becomes an explicit runtime input.

So yes: for heterogeneous page ranges known only at execution time, a custom wrapper around DoclingConverter is the right direction, unless your workload can be split into same-range batches.

If that matches your use case, please mark this as answered so others can find the runtime-parameter boundary quickly.

[ganny-gitaa]

Thank you! I'll write a wrapper to handle this.