Describe the bug
When a custom HTTP content-extraction provider exceeds Papra's request timeout, Papra logs the failure and proceeds to the next configured strategy, but the in-flight request to the external provider is not cancelled. The provider can continue processing and consume resources even though Papra will discard its eventual response.
What happened?
I run Papra self-hosted with:
CONTENT_EXTRACTION_STRATEGY=custom-http,internal
CONTENT_EXTRACTION_CUSTOM_HTTP_URL=http://<custom-ocr-service>/extract
The custom service renders PDFs and sends pages to a local vision model. For a 703,141-byte PDF:
- Papra started
extract-document-file-content.
- The custom HTTP request failed after roughly five minutes with:
FetchError: [POST] "http://<custom-ocr-service>/extract": <no response> fetch failed
- Papra immediately used the
internal strategy and stored the fallback text.
- The external OCR service continued processing the PDF for approximately another 52 minutes and eventually returned HTTP 200.
- The late OCR response was discarded; it did not replace the fallback content.
The behavior appears to be enabled by the custom HTTP strategy using ofetch(..., { timeout }) without a caller-provided AbortSignal, combined with the fallback loop continuing after the strategy promise rejects. The server timeout middleware also uses Promise.race without cancelling the underlying operation.
Expected behavior
When Papra stops waiting for an external extraction request, it should either:
- propagate cancellation/deadline information to the provider; or
- explicitly document that the provider may continue running after Papra times out, and provide a safe mechanism for providers to detect cancellation.
Fallback should not leave expensive external OCR work running indefinitely.
System information
- Papra: self-hosted Docker rootless image, current deployment based on the 26.6.x line
- Extraction strategies:
custom-http,internal
- External provider: private HTTP OCR adapter backed by Ollama
- Deployment: Docker Compose
- Document type: PDF
Relevant source locations:
apps/papra-server/src/modules/documents/content-extraction/content-extraction-strategies/custom-http/custom-http.content-extraction-strategy.usecases.tsapps/papra-server/src/modules/documents/content-extraction/content-extraction.usecases.tsapps/papra-server/src/modules/app/middlewares/timeout.middleware.ts
Related: #1364 / #1365 addressed configurable timeouts for some external providers, but does not appear to address cancellation propagation for custom HTTP extraction.
Describe the bug
When a custom HTTP content-extraction provider exceeds Papra's request timeout, Papra logs the failure and proceeds to the next configured strategy, but the in-flight request to the external provider is not cancelled. The provider can continue processing and consume resources even though Papra will discard its eventual response.
What happened?
I run Papra self-hosted with:
The custom service renders PDFs and sends pages to a local vision model. For a 703,141-byte PDF:
extract-document-file-content.internalstrategy and stored the fallback text.The behavior appears to be enabled by the custom HTTP strategy using
ofetch(..., { timeout })without a caller-providedAbortSignal, combined with the fallback loop continuing after the strategy promise rejects. The server timeout middleware also usesPromise.racewithout cancelling the underlying operation.Expected behavior
When Papra stops waiting for an external extraction request, it should either:
Fallback should not leave expensive external OCR work running indefinitely.
System information
custom-http,internalRelevant source locations:
apps/papra-server/src/modules/documents/content-extraction/content-extraction-strategies/custom-http/custom-http.content-extraction-strategy.usecases.tsapps/papra-server/src/modules/documents/content-extraction/content-extraction.usecases.tsapps/papra-server/src/modules/app/middlewares/timeout.middleware.tsRelated: #1364 / #1365 addressed configurable timeouts for some external providers, but does not appear to address cancellation propagation for custom HTTP extraction.