API-ingested documents have file_path=None causing 500s on status endpoints – intended design?

[filippoloddo]

Hi maintainers,

I’m running LightRAG Server (v1.4.9.x) and noticed the following behavior:

• Documents ingested via /documents/text or /documents/upload legitimately have file_path = None
• Status endpoints such as:
  • /documents/paginated
  • /documents/track_status/{track_id}
    attempt to serialize these documents using DocStatusResponse
• DocStatusResponse.file_path is currently defined as a required str
• This results in a Pydantic validation error and HTTP 500 for otherwise valid requests

I verified this is happening in:
api/routers/document_routes.py when constructing DocStatusResponse.

From a user perspective, API-ingested documents are first-class, so file_path=None seems valid state.
This leaves two possible design directions:

1. Make file_path optional in DocStatusResponse
2. Assign a synthetic path/URI for API-ingested documents (e.g. api://text/<doc_id>)

Before opening a PR, I wanted to ask:

• What is the intended invariant for file_path?
• Is API ingestion expected to populate a synthetic file path, or should the response schema allow None?

Happy to contribute a fix once the intended direction is clarified.