Why are files stuck in 'Scanning' and Core Workflow returning 504 in MetaDefender MFT?

Info:

  • This article applies to MetaDefender Managed File Transfer (MFT) 3.9.3.0 and earlier

Issue:

In MetaDefender MFT 3.9.3.0 and earlier versions, files may remain in Scanning when MetaDefender Core is slow or unavailable. If scan requests exceed MFT’s retry and timeout limits, the MFT console may display a 504 Gateway Timeout. This usually indicates delayed Core processing, queue congestion, or inconsistent routing through the load balancer—not a problem with the uploaded file.


Technical background and common causes:

During the incident, one MetaDefender Core instance was interrupted, reducing cluster capacity and causing jobs to queue on the remaining instance. As response times exceeded MFT’s timeout, scan requests were cancelled and retried; without MFT Smart Routing or load-balancer session affinity, related requests could reach different Core nodes and prolong recovery, leaving files in Scanning.


The same Core-side capacity strain also caused the read-only workflow lookup (/vault_rest/settings/mdcore/workflows) to exceed nginx’s 360-second read timeout, producing a downstream 504 Gateway Timeout. This lookup does not use the scan-cancellation path.

WARN Timeout elapsed for filename: <redacted>. Killing the request... ERROR scan request failed; job: <redacted>; request cancelled ERROR upstream timed out while reading response header GET /vault_rest/settings/mdcore/workflows

Workarounds:

While restoring Core capacity, reduce or pause non-critical upload and scan traffic. Remove unhealthy Core nodes from load-balancer rotation until recovery and validation are complete. Then restart MFT services.

Resolution:

Support:

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.