Extraction errors silently swallowed, producing misleading failure message

When an extractor's extract() call throws — for example pdfjs encountering a malformed or password-protected PDF — the catch { continue; } block discards the error and moves to the next extractor. With only one extractor registered, all extractors are skipped, extractDocumentContent returns null, and extractPdfContent re-raises "PDF extraction disabled or unavailable". This is factually incorrect: the extractor is enabled and reachable; it failed because of the document itself. The previous code let pdfjs errors propagate to the caller directly, giving a meaningful stack trace. At minimum the caught error should be surfaced (e.g., logged or re-thrown when no subsequent extractor succeeds).

This is a comment left during a code review.
Path: src/media/document-extractors.runtime.ts
Line: 51-61

Comment:
**Extraction errors silently swallowed, producing misleading failure message**

When an extractor's `extract()` call throws — for example pdfjs encountering a malformed or password-protected PDF — the `catch { continue; }` block discards the error and moves to the next extractor. With only one extractor registered, all extractors are skipped, `extractDocumentContent` returns `null`, and `extractPdfContent` re-raises "PDF extraction disabled or unavailable". This is factually incorrect: the extractor is enabled and reachable; it failed because of the document itself. The previous code let pdfjs errors propagate to the caller directly, giving a meaningful stack trace. At minimum the caught error should be surfaced (e.g., logged or re-thrown when no subsequent extractor succeeds).

How can I resolve this? If you propose a fix, please make it concise.

Uncaught exception from factory function causes entire extractor loading to fail

exported() is called without a try/catch. If a create*DocumentExtractor factory throws (e.g., a plugin that probes for native dependencies at construction time), the exception propagates out of collectExtractorFactories → loadBundledDocumentExtractorEntriesFromDir → resolvePluginDocumentExtractors, which is then absorbed by the catch { return null; } in extractDocumentContent. The end result is the same misleading "disabled or unavailable" error, and a factory bug in one plugin silently disables all extractors in that module. Wrapping the exported() call in its own try/catch and skipping (or logging) failing factories would isolate the blast radius.

This is a comment left during a code review.
Path: src/plugins/document-extractor-public-artifacts.ts
Line: 66-69

Comment:
**Uncaught exception from factory function causes entire extractor loading to fail**

`exported()` is called without a try/catch. If a `create*DocumentExtractor` factory throws (e.g., a plugin that probes for native dependencies at construction time), the exception propagates out of `collectExtractorFactories` → `loadBundledDocumentExtractorEntriesFromDir` → `resolvePluginDocumentExtractors`, which is then absorbed by the `catch { return null; }` in `extractDocumentContent`. The end result is the same misleading "disabled or unavailable" error, and a factory bug in one plugin silently disables all extractors in that module. Wrapping the `exported()` call in its own try/catch and skipping (or logging) failing factories would isolate the blast radius.

How can I resolve this? If you propose a fix, please make it concise.

Propagate extractor failures for matching MIME handlers

When a matching document extractor throws (for example, a malformed/corrupt PDF in extractor.extract), this catch swallows the error and falls through as if no extractor existed; extractPdfContent then rethrows a generic "disabled or unavailable" message. That regresses diagnostics compared with the previous direct PDF.js path, because real parsing/runtime failures are now misreported as plugin disablement, making operator triage and user error handling inaccurate.

Useful? React with 👍 / 👎.