When image bytes for a multimodal task cannot be read via FileService
(e.g. tenant.StorageEngineConfig.MinIO is empty while the image was
saved using the global MINIO_* env vars), the previous code fell back
to the HTTP downloader, which rejected the provider:// URL with
"unsupported URL scheme". The asynq handler then returned an error,
asynq retried until exhaustion, and the per-knowledge "pending images"
counter was never decremented — leaving the document stuck in
"processing" indefinitely (issue #1282).
Changes:
- ImageMultimodalService now holds a default FileService and
resolveFileServiceForPayload falls back to it when the tenant-scoped
storage config cannot produce a usable service, mirroring the
write-side fallback in knowledgeService.resolveFileService.
- Extract readImageBytes: provider:// URLs are read exclusively via
FileService and never handed to the HTTP downloader.
- On unrecoverable read failure for a single image, log and skip that
image but still call checkAndFinalizeAllImages so the parent
knowledge can progress to post-processing.
Fixes#1282
wizardchen
8b2a36d759