Describe the bug
Files uploaded to composition attachment entities can get permanently stuck in Scanning status if the server crashes while a malware scan is in progress. On the next server start, no mechanism exists to detect and retry these orphaned scans.
To Reproduce
- Upload a file to an entity that uses the Attachments aspect
- Kill the server while ScanAttachmentsFile is being processed (before updateStatus writes Clean/Infected/Failed)
- Restart the server
- The attachment remains in Scanning status indefinitely — no retry is triggered
Expected behavior
On startup, any attachment rows with status = 'Scanning' should be detected and re-queued for scanning, since the scan that set that status clearly never completed.
Additional context
We implemented a workaround on the application side by hooking into cds.once('served') and querying all @_is_media_data entities for stuck rows, then re-emitting ScanAttachmentsFile for each. However this belongs in the plugin itself.
If you agree with this, I am happy to support further by submitting a PR.
Describe the bug
Files uploaded to composition attachment entities can get permanently stuck in Scanning status if the server crashes while a malware scan is in progress. On the next server start, no mechanism exists to detect and retry these orphaned scans.
To Reproduce
Expected behavior
On startup, any attachment rows with status = 'Scanning' should be detected and re-queued for scanning, since the scan that set that status clearly never completed.
Additional context
We implemented a workaround on the application side by hooking into cds.once('served') and querying all @_is_media_data entities for stuck rows, then re-emitting ScanAttachmentsFile for each. However this belongs in the plugin itself.
If you agree with this, I am happy to support further by submitting a PR.