feat(presets): expose parsing strategies via /presets/options

[andyne13]

What

Exposes parsing_strategies on GET /presets/options so the admin preset editor can drive its parsing-strategy dropdown from the backend instead of a hardcoded list.

Closes #518.

Why

The UI hardcoded marker + pymupdf and had drifted from IndexationPipelineConfig.parsing_strategy = Literal["pymupdf", "marker", "docling"] — docling was missing. Chunking/retrieval/reranker options already come from this endpoint; parsing didn't.

Change

• PresetOptionsResponse gains parsing_strategies: list[str].
• The /options handler populates it from get_args(IndexationPipelineConfig.model_fields["parsing_strategy"].annotation) — derived from the validated Literal, so the option list can never drift from what the config accepts.

Test

test_preset_options_crud_and_rename now asserts parsing_strategies == {pymupdf, marker, docling}. Ruff clean; response model verified to build with the derived list.

Follow-up

Frontend switch (read parsing_strategies from options instead of the hardcoded <SelectItem>s) lands separately on the admin-UI branch.

Summary by CodeRabbit

• New Features

  • The preset options endpoint now exposes available parsing strategies (pymupdf, marker, and docling) in its response.

• Tests

  • Updated integration tests to validate parsing strategies in the preset options endpoint response.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 69d4179e-7437-48aa-9966-d17dea14c475

📥 Commits

Reviewing files that changed from the base of the PR and between 14301a4 and af10e67.

📒 Files selected for processing (3)

• openrag/api/routers/admin/presets.py
• openrag/api/schemas/admin/preset_schemas.py
• tests/integration/api/test_presets.py

---

📝 Walkthrough

Walkthrough

The /presets/options endpoint now returns a parsing_strategies field derived at module load time from IndexationPipelineConfig's parsing_strategy Literal annotation using typing.get_args. The PresetOptionsResponse schema gains a parsing_strategies: list[str] field, and the integration test asserts the returned set is {"pymupdf", "marker", "docling"}.

Changes

Expose parsing_strategies on /presets/options

Layer / File(s)	Summary
Schema field, derivation logic, endpoint wiring, and integration test openrag/api/schemas/admin/preset_schemas.py, openrag/api/routers/admin/presets.py, tests/integration/api/test_presets.py	PresetOptionsResponse gains parsing_strategies: list[str]; the router imports get_args and IndexationPipelineConfig, computes _PARSING_STRATEGIES from the Literal annotation, and passes it to the /options response; the integration test asserts the returned set equals {"pymupdf", "marker", "docling"}.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐇 Hippity-hop, the strategies align,
No more hardcoding down the frontend vine!
get_args plucks the Literal's truth,
docling joins marker and pymupdf — forsooth!
The options endpoint now tells no lies,
A rabbit-approved fix under open skies! 🌟

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: exposing parsing strategies via the /presets/options endpoint.
Linked Issues check	✅ Passed	The PR fully implements the requirements from issue #518: parsing_strategies field added to PresetOptionsResponse, derived from IndexationPipelineConfig using get_args(), and test updated to verify all three strategies (pymupdf, marker, docling) are exposed.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to exposing parsing strategies through the /presets/options endpoint as specified in the linked issue; no extraneous modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/expose-parsing-strategies

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Ahmath-Gadji]

LGTM — clean and correctly scoped. Verified the derivation resolves to ["pymupdf", "marker", "docling"] and that deriving from IndexationPipelineConfig's Literal (rather than parser_registry.list_registered()) is the right source of truth, since the registry also holds non-PDF/auto-dispatched parsers (docx, image, eml, audio, …). CI is green and the new test covers it.

Verified live end-to-end

Against a running instance I exercised the full create → attach → resolve flow:

1. GET /presets/options → parsing_strategies: ["pymupdf", "marker", "docling"] ✅
2. POST /presets/ with {"name":"pymupdf-fast","preset_type":"indexation","config":{"parsing_strategy":"pymupdf"}} → 201
3. PATCH /partition/{p} with {"indexation_preset":"pymupdf-fast"} → 200
4. GET /partition/{p}/config → indexation_preset: pymupdf-fast, resolved indexation_pipeline.parsing_strategy: pymupdf ✅

So the option flows correctly through preset creation, partition assignment, and resolved config. (Step 4 stops at the resolved config on purpose — see the gap below for why an actual parse wouldn't yet reflect it.)

One known gap (out of scope for this PR) — described against this branch (refactor/hexagonal)

The parsing_strategy this endpoint now exposes is not yet honored at parse time on this branch. The per-partition indexation_config is plumbed all the way into the pipeline, and the chunker and embedder already respect it (their factories are wired). The parser is the exception:

• IndexerPool builds a single parser = DocSerializerBridgeParser(config=cfg) and calls build_indexing_pipeline(parser=..., chunker_factory=..., embedder_factory=...) without a parser_factory (openrag/services/workers/indexer_pool.py).
• Because no parser_factory is wired, _select_parser(config) (openrag/services/workers/pipeline_builder.py) never reaches its config.parsing_strategy branch and just returns that single bridge parser. That config.parsing_strategy line is, in fact, the only place the field is read in the whole parse path on this branch — and it's currently dead.
• The bridge then selects the concrete loader by file extension / mimetype from get_loader_classes(config), which reads the global config.loader.file_loaders map. The per-file override (_legacy_loader_config) only toggles image captioning — it never touches the PDF loader.

Net effect: a partition set to pymupdf still parses PDFs with whatever the global file_loaders.pdf is. Exposing the option here is still correct and useful — it just isn't wired into actual parsing yet.

Why the fix waits for #513

#513 replaces DocSerializerBridgeParser with the new ParserDispatcher, but keeps the same shape: IndexerPool still builds one global dispatcher and passes no parser_factory, and the dispatcher resolves the PDF backend from the global config.loader.file_loaders.pdf. So the gap carries straight over to the consolidated parser path. Fixing it on this branch would mean wiring the now-legacy bridge, only to rewrite it once #513 lands.

A separate PR will therefore wire the partition's parsing_strategy into the parse path after #513 is merged, using the existing (currently-unused) parser_factory / _select_parser seam with the global loader as fallback. It must also address the operational side: marker/docling require provisioned GPU pools, so the follow-up should validate the selected strategy against available backends (or document the provisioning requirement).

Approving so this can merge; the wiring is tracked as the follow-up above.