What happens when a batch is closed during file upload in MetaDefender Core?
- This article applies to MD Core version 5.15.0 and older
- A known edge case where a batch is closed before a file is fully uploaded by the client, resulting in specific error logs and potential queue size increasing
- From version 5.15.1, the behavior will be fixed
Issue Description
During scanning operations, the following flow can occur:
- Client initiates a POST request to upload a file as part of a scan batch.
- Before the file transfer completes, the associated batch is closed (possibly due to timeout or client behavior).
- As a result, MetaDefender Core logs the following warning:
CEF:0|OPSWAT|MSCW|5.14.0|core.workflow|Batch closed during file upload|2|OMSbatch_id=6a1618d6fefe437aa2a844ce8def5481 OMSdata_id=4e145bc0cde541f3b803e98efd691c95 OMSmsgid=3528This indicates that the file was discarded because its batch was already terminated.
Expected Behavior
MetaDefender Core attempts to send an HTTP 400 Bad Request response to the client to notify it that the file was discarded due to premature batch closure.
Observed Behavior (Edge Case)
In high-load environments or due to client-side behavior (e.g., connection timeout), the connection might already be closed before Core can send the response.
This leads to a follow-up error:
CEF:0|OPSWAT|MSCW|5.14.0|common.workflow|Workflow block ended with exception|3|OMSblock=RestResponse OMSworkflow_id=lms::workflow::RestWorkflowExecutor(0x22288d4a530, name = "WF-127.0.0.1:61898") OMSerror=Channel failed with error An established connection was aborted by the software in your host machine. OMSmsgid=97This confirms that the attempt to inform the client failed, and the connection was forcefully aborted. As a result, MD Core queue size might unexpectedly keep increasing dues to incompleted process in queue.
In version 5.15.1 or later, the issue will be improved. Even if Core cannot respond to the client, the workflow will:
- Continue execution
- Free the scan queue to avoid bottlenecks or resource leakage.
This enhancement ensures graceful degradation even in unstable network scenarios.
Workaround / Recommendations
No client-side changes are required unless frequent disconnections occur. In such cases:
- Review client upload behavior and network reliability.
- Ensure sufficient timeouts and retry logic are implemented on the client side.
If you require further assistance, please follow these instructions on How to Create Support Package?, before creating a support case or chatting with our support engineer.