bug: rc.29 hard-coded 60s timeout?

[scetu]

Description

xberg rc.29 seems to have hard-coded ~60s timeout on /v1/convert/file endpoint used by Open WebUI (Docling Engine). If document is big or slow via VLM pipeline, it fail with HTTP 500.
WARN tower_http::trace::on_failure: response failed classification=Status code: 500 Internal Server Error latency=60007 ms

I tried these variables, but they don't help:

• extraction_timeout_secs = 1800
• vlm_config.timeout_secs = 1200

Summary by AI

Issue: Inbound HTTP requests to xberg serve (specifically the /v1/convert/file endpoint used by Open WebUI) are being terminated with an HTTP 500 Internal Server Error after exactly ~60 seconds.

Root Cause:
The failure is caused by a hard-coded tower::timeout layer within xberg's inbound Axum server stack. This is evidenced by logs showing tower_http::trace::on_failure with latency=60007 ms and a 500 status code.

Technical Details:

• Ineffective Configs: Existing settings—extraction_timeout_secs (library level) and vlm_config.timeout_secs (outbound VLM level)—do not affect this boundary because the timeout occurs at the inbound HTTP request layer.
• Lack of Control: As of rc.29, there is no documented environment variable (XBERG_*), CLI flag, or [server] TOML key available to modify this inbound request timeout.
• Downstream Impact: Open WebUI receives a 500 error, causing document uploads to fail or "disappear" when processing (e.g., via VLM OCR) exceeds the 60s wall-clock limit.

Requested Fix:

1. Expose the inbound HTTP request timeout as a configurable setting (via environment variable, CLI flag, or TOML key).
2. Alternatively, implement an asynchronous (submit-and-poll) pattern for the Docling compatibility endpoint to avoid holding synchronous connections for long-running extractions.

Steps to reproduce

Upload document which needs OCR (PDF without Text layer) into Open WebUI, after 60 seconds warning in Open WebUI will appear and in xberg's logs is tower_http::trace::on_failure: response failed classification=Status code: 500 Internal Server Error latency=60007 ms but the VLM generation is still runing in backend.

Relevant files and configuration

xberg.toml

use_cache                  = true
enable_quality_processing  = true
include_document_structure = true
output_format              = "markdown"
force_ocr = true

[ocr_strategy]
mode = "scanned_pages"
min_confidence = 0.6
extraction_timeout_secs = 1800
max_concurrent_extractions = 6
qr_codes = true

[acceleration]
provider = "cpu"

[content_filter]
include_headers      = true
include_footers      = true
include_watermarks   = true
strip_repeating_text = false

[pdf_options]
extract_images             = true
extract_tables             = true
extract_metadata           = true
extract_annotations        = true
extract_form_fields        = true
allow_single_column_tables = true
reading_order              = true
ocr_inline_images          = false

[pdf_options.hierarchy]
enabled      = true
k_clusters   = 6
include_bbox = true

[layout]
confidence_threshold       = 0.7
apply_heuristics           = true
table_model                = "tatr"
table_overlap_preference   = "content"
enable_chart_understanding = true

[images]
extract_images      = true
classify            = true
target_dpi          = 300
max_image_dimension = 4096
max_images_per_page = 50
include_page_rasters = false
run_ocr_on_images   = false
inject_placeholders = false

[ocr]
backend     = "vlm"
language    = ["eng"]
auto_rotate = true
output_format = "markdown"
vlm_prompt = """
You are a document OCR transcription engine. Convert the visible content of this single page image into clean GitHub-flavored Markdown. Transcribe; do not interpret, summarize, or answer.
"""

[ocr.vlm_config]
model        = "Qwen3.5-27B-GGUF"
base_url     = "https://api.example.com/v1"
api_key      = "your-api-key-here"
timeout_secs = 1200
max_retries  = 3
temperature  = 0.0
max_tokens   = 8192

[pages]
extract_pages       = true
insert_page_markers = true
marker_format       = "<!-- PAGE {page_num} -->"

[language_detection]
enabled         = true
min_confidence  = 0.8
detect_multiple = true

[Goldziher]

Thanks for reporting, will check it tomorrow

[Goldziher]

Fixed in v1.0.0-rc.31 (42bda9af70).

There is no hard-coded inbound HTTP timeout layer in xberg serve — the ~60s limit was liter-llm's built-in default on the outbound VLM client, applied whenever timeout_secs was left unset. The tower_http latency=60007 ms line is the trace layer reporting the 500 that propagated up from the failed VLM call, not a layer enforcing a timeout.

The VLM OCR path now defaults to 300s when timeout_secs is unset, and an explicit [ocr.vlm_config] timeout_secs is honored end-to-end. Your config sets timeout_secs = 1200 explicitly, which is preserved post-fix, so the 60s failure should be gone.

If uploads still 500 at ~60s after upgrading, that would indicate your [ocr.vlm_config] block isn't being loaded into the server's default config (a config-loading issue, separate from this timeout) — please reopen with your full config and we'll trace it. Note extraction_timeout_secs governs library extraction, not the VLM call.

Please re-test with rc.31 or newer.