1874 failed attch ios trail

[S-S-T]

Mobile Client Compatibility — Failed Attachment Handling (iOS/Android) #1874

Summary

This branch implements the server-side API contract for failed attachment handling following ClamAV pre-disk scanning, establishing the foundation for mobile client compatibility.

---

Changes Made

• Modified service/src/adapters/observations/adapters.observations.controllers.web.ts to handle ClamAV rejected attachments by storing a placeholder image (SecError.png) in place of the rejected file and returning a structured response including contentStored: false, error, and failures fields
• Added service/src/assets/SecError.png — placeholder image displayed when an attachment is rejected by ClamAV
• Merged ClamAV pre-disk scanning work from branch predisk-scanning-1756

---

Response Structure on Rejection

{
    "id": "",
    "fieldName": "",
    "observationFormId": "",
    "lastModified": "",
    "contentType": "",
    "name": "",
    "size": "",
    "oriented": "",
    "thumbnails": [],
    "contentStored": false,
    "url": "",
    "relativePath": "",
    "error": "File failed security scan",
    "failures": [
        {
            "file": "eicar.txt",
            "error": "File failed security scan"
        }
    ]
}

---

Testing

• Tested locally with clean file upload — success response correct
• Tested locally with eicar.txt — rejection response matches agreed structure
• Verified on test environment with ClamAV running

---

Dependencies

• Requires ClamAV running with CLAM_AV_URL env variable set
• Branched from develop with predisk-scanning-1756 merged in

---

Open Items

• iOS/Android client testing against new response structure pending
• Granular failure messaging on mobile TBD pending iOS/Android findings

[paulsolt-ofsw]

When I tried again from iOS the file is not removed on mobile.

<test.mage.geointapps.com>

2026-4-21.ClamAV.code.review.mp4

If we don't update the lastModified data on the server, than the iOS app never attempts to update things. Something feels off around this logic for swapping to a placeholder image.

I still have the "infected" file in my local storage on iOS, and I never see the "security image".

There are a lot of changes on this PR that don't appear to be related to the actual work.

I'm a little concerned to merge this as is, because of the scope of changes, and chance for regressions.

[S-S-T]

Merging this PR is still a ways off. At this point, not comfortable--and won't be until there is requisite clarity and proof. Furthermore, the PR's scope is incomplete/incorrect. The modifiedDate issue must be addressed in order for iOS processes to flow as intended. The showing of the canned image is still unclear and may require further discussion.