Thanks for working on this. I reviewed the separate raganything_multimodal_status KV namespace approach against the current LightRAG DocProcessingStatus model.

I don't think this should be merged as an isolated small fix yet. Moving multimodal_processed out of doc_status avoids older LightRAG deserialization issues, but it also changes the status semantics for newer LightRAG versions where DocProcessingStatus.multimodal_processed is now a first-class field and can drive PROCESSED -> PREPROCESSED presentation while multimodal processing is incomplete.

Before this can land, I think we need at least:

• a migration or read-fallback plan for existing doc_status records that already contain multimodal_processed, otherwise is_document_fully_processed() can regress until documents are reprocessed;
• tests covering get_document_processing_status() / is_document_fully_processed() and the LightRAG server pagination failure this is meant to avoid;
• an explicit plan for how this coordinates with fix: create doc_status even when LightRAG lacks multimodal insert args #255, because both PRs touch the same doc_status / multimodal completion area and will conflict semantically;
• a decision on whether LightRAG server APIs should continue to reflect multimodal completion state, or whether that state becomes RAG-Anything-only metadata.

So I would hold this for a design pass rather than merging it directly.

@peterCheng123321 Thanks for raising this — closing in favor of #255 (now merged into main), which incorporates the core idea you proposed here.

Your direction was right: storing multimodal completion state outside doc_status is needed for compatibility with LightRAG versions whose DocProcessingStatus dataclass rejects unknown kwargs. #255 ships exactly that, but as a fallback rather than a wholesale replacement:

• it still tries to write multimodal_processed into doc_status first (so newer LightRAG versions that natively support the field keep driving PROCESSED -> PREPROCESSED presentation as designed in Add PREPROCESSED (multimodal_processed) status for multimodal document processing LightRAG#2211 / Refact: Add Multimodal Processing Status Support to DocProcessingStatus LightRAG#2248)
• if doc_status.upsert rejects the field, it transparently falls back to a separate multimodal_status KV namespace (same approach you took here)
• read paths (is_document_fully_processed, get_document_processing_status, _process_multimodal_content's skip-already-done check) consult both stores via _get_multimodal_processed_flag

This avoids the migration concern I raised in the earlier review: existing doc_status records that already contain multimodal_processed keep working without reprocessing, and #91 / #119's DocProcessingStatus deserialization error is also fixed because we no longer write the field unconditionally.

If you spot any case where #255's approach still misbehaves on your setup, please open a new issue with reproduction details — happy to iterate. Really appreciate the contribution.