Uploaded files leak to disk forever when a later field in the same multi-file submission fails validation

This bug was found through code review, not injected -- it is a real gap in the shipped code. For any form with more than one type: "file" field (e.g. "resume" + "photo" on a job-application form), a submitter who gets exactly one of the two files wrong (wrong content type, too large) triggers a 422 as expected -- but the other, validly-uploaded file is left sitting on disk forever, with no database row referencing it (the whole submission, including any Attachment rows, is rolled back). Nothing in this codebase ever queries "files on disk with no matching Attachment row," so there is no automatic cleanup path either. This is a slow, silent disk-usage leak on the shared uploads volume: every retried multi-file submission where the submitter fixes their mistake and resubmits leaves one more orphaned file behind from the failed attempt. At any real submission volume, this becomes an on-call/ops problem eventually -- unexplained disk growth on the uploads volume that standard "find unreferenced files" tooling cannot even detect without being purpose-built for this leak, since the whole premise of the leak is that there is no reference to search for.

In create_submission (app/blueprints/submissions/routes.py), file fields are processed in a loop. Each iteration calls validate_and_store_file, which -- as soon as its own checks (content type, size) pass -- calls file_storage.save(dest_path) immediately, writing real bytes to disk. If validation fails on a later field in the same loop, the code calls db.session.rollback() and returns a 422. db.session.rollback() discards the pending Submission/Attachment database rows for this request -- but it has no effect whatsoever on files already written to disk by earlier iterations of the same loop. Those files are real, on-disk, and now permanently orphaned.

cd flask/feedback_service export FLASK_ENV=testing FLASK_ENV=testing .venv/bin/python -m pytest ticket_tests/test_ticket_07_orphaned_upload_files_on_rollback.py -v

See that test file's docstring for why it exercises validate_and_store_file and

db.session.rollback() directly rather than through two real HTTP file fields: which of two

file fields is processed first over HTTP depends on Python's per-process string-hash seed,

since file_field_names is a set, so the specific HTTP reproduction is non-deterministic

across runs even though the underlying defect is not.

This is a transaction-boundary bug that spans two different systems: the SQL database (which db.session.rollback() genuinely does undo) and the filesystem (which it does not, and cannot -- a file write is not part of any SQL transaction). Any code that does "write side effects, then maybe roll back the DB" needs an explicit plan for the side effects that are not inside that transaction. This is a common shape of bug anywhere a request handler mixes a database write with an external effect (a file write, an outbound API call, a queued Celery message) inside the same error-handling path -- exactly the class of bug that only shows up under a specific ordering of failures, long after the happy path has shipped and been trusted.

Look at the loop in create_submission that iterates file_field_names and calls validate_and_store_file for each one. Consider: what does this function body need to know, or track, in order to undo a file write the way db.session.rollback() undoes a database write? Look at os.remove in Python's standard library, and think about where the cleanup needs to happen relative to the existing if error: db.session.rollback(); return ... line -- both for the field that just failed, and for any field(s) that succeeded earlier in the same loop.