<-- Back

Unreferenced file with state 'New' triggers critical errors due to auto-commit entries not cleaned up after a restart/redeployment

Issue

When a FileDocument object (inherits from system$filedocument) is auto-committed, the following critical may be logged in the application's log after an app restart or redeployment.

CRITICAL - Core: Prevented deletion of one or more files that are still in use. Please contact Mendix Support to prevent this from happening in the future. (UUIDs: [FILE-IDs])

The error indicates that the Mendix unreferenced file cleanup process attempted to delete a physical file from storage, but a safety check prevented the action because the file's identifier is still registered as being actively referenced by a (auto-committed) FileDocument object in the application database.

Environment

Applications hosted in any deployment type

Cause

An auto-committed FileDocument creates an entry in the system$unreferencedfile table with state 'New' to temporarily hold the file content.  This entry is correctly associated to a user session and is intentionally skipped by the regular file cleanup process while that session is active.

During application restart or redeployment, all existing sessions are removed from the database. The removal clears the association between the unreferenced file and the session, but it skips the deletion of auto-committed objects. Consequently, the unreferencedfile entries and its associated auto-commit entry remain in the database, but the unreferencedfile loses its association to a session. 

On the next run of the cleanup process, this orphaned unreferencedfile entry is identified as a candidate for deletion, but the corresponding file appears to still be referenced, triggering the critical error.

To dertermine if the critical error is caused by auto-commit, follow these steps:

  • Cross-reference the fileKey attribute in the system$unreferencedfile table entries that are triggering the error message with the __uuid__ attribute in the system$filedocument table. This will identify the FileDocument instances linked to the unreferencedfile entries.
  • Cross-reference the id of these system$filedocument entries with the id in the system$autocommitentry table. This will show which auto-committed file documents have corresponding unreferenced file entries.

Solution / Workaround

This is a known issue in the backlog of Runtime team, but since auto-commit mechnism may be deprecated in the near future, the ETA is not determined. 

As a workaround, any auto-committed FileDocument should be explicitly committed or deleted within the same user session in which it was created. An explicit commit removes the object from the auto-commit state, ensuring proper lifecycle management. If the file is temporary, explicit deletion is also effective. 

Internal information related

  • 264129, 261453
  • RUN-4892
  • C3T260XGA/p1760710252688099

Additional information

Have more questions? Submit a request

0 Comments

Article is closed for comments.

To provide feedback, please open a ticket here. Don't forget to include the article's URL along with the feedback you would like to provide.