Unsupported file formats trigger automatic chunking: explore parser-aware eligibility checks

Problem

Uploading a file that the chunking parser cannot handle can still automatically create a chunking task, leaving a successfully uploaded file with a misleading “Chunking failed” status and a retry action that cannot resolve the underlying format limitation.

Observed on a self-hosted deployment with a .dwg file (approximately 100 KB). The resulting error was:

[DocumentLoaderError]: Unsupported file type [undefined], please check your file is supported, or create report issue here: https://github.com/lobehub/lobe-chat/discussions/3550

Steps to reproduce

1. Upload a .dwg file through the resource/file manager.
2. Upload succeeds, but automatic chunking is triggered.
3. The parser does not recognize the extension and the file displays “Chunking failed”.

Expected: the file can remain available for storage/download without creating a chunking task that is known to be unsupported. The UI should distinguish unsupported parsing from a retryable processing failure.

Current logic

The current canary implementation of packages/utils/src/isChunkingUnsupported.ts only excludes MIME types beginning with image, video, or audio. Its own comment notes that returning false does not mean the format is supported.

The file manager uses the inverse of that predicate to decide whether to automatically request chunking. Meanwhile, ChunkingLoader.getType() determines support from the filename. Unknown extensions can therefore pass the initial MIME-based check and fail only after a task has been created. Empty or generic MIME values are also not excluded by this predicate.

Discussion: could we explore a more suitable eligibility check?

Would it make sense to separate upload/storage support from parsing/chunking capability, and use a positive capability check before automatically scheduling chunking?

Some possibilities to discuss:

• Derive eligibility from the same format registry or capability resolver used by the actual parser, rather than maintaining a separate frontend allowlist.
• Account for filename extensions, missing/generic MIME types, and any configured parsing backend, so future parser support is not accidentally blocked.
• Apply the same policy on the server for other entry points and explicit/batch chunking requests.
• Represent unsupported formats as “not available for parsing” rather than a processing failure with an ineffective retry action.

These are discussion points rather than a prescribed implementation. A parser-backed allowlist seems more predictable for automatic chunking, but it would be useful to understand whether there are intended fallback or extensibility requirements that call for a different approach.

This report is about handling unsupported formats gracefully; adding a DWG parser is outside its scope.

Related format-support discussion: #3550.