ABP Suite: Issue with Default Image Upload Behavior in ABP Suite (Upload Triggered Before Create Action) #10546

2 Answer(s)

• 

  0

  AI-Bot created 8 hours ago

  Support Team ABP Agent

  • In the ABP Suite-generated Blazor CRUD pages, the “File” property uses a select file → upload immediately UX. With BLOB Storage/File Management this means a FileDescriptor + blob content can be created before the main entity is saved. If the user closes the modal / refreshes, those uploaded blobs can remain orphaned unless you add a cleanup strategy.
  • There isn’t a built-in ABP Suite switch (template option) that changes this to “upload only on Save” for generated pages (no verified source available for a Suite extension point that flips this behavior).

  Recommended ABP-style approaches

  A) “Upload on Save” (recommended if you want zero orphan risk)

  Implement the create/edit form so it does not call the server on file selection. Instead:

  1. On file selection, keep the file in memory (or stream) on the Blazor side and only show a preview.
  2. When the user clicks Save, call your Application Service CreateAsync(...) and pass the file content as IRemoteStreamContent (or a byte[] if small), then inside the same application service method:
     • Create the entity
     • Save the blob
     • Store the blob/file id on the entity
     • Commit once (same unit of work)

  This matches ABP’s general “do it in the application service in a single use-case” style and avoids a “temporary upload” concept entirely.

  B) Keep immediate upload, but add an automatic cleanup (recommended if you want to keep Suite UX)

  If you keep the default immediate upload, use a “temporary upload” + scheduled cleanup pattern:

  1. When the file is uploaded, mark it as temporary (e.g., store a flag/metadata, or put it under a “temp/” naming convention, or store it in a dedicated container).
  2. When the user clicks Save and the entity is created, “finalize” the file:
     • clear the temporary flag (or move/rename)
     • associate it with the created entity
  3. Run a background job (periodic worker) that deletes temporary files older than X minutes/hours (and their descriptors).

  ABP’s Blob Storing API supports deleting blobs, so the cleanup job can safely remove old temporary items.

  C) Compensating cleanup on Cancel (best-effort only)

  In the modal’s Cancel/Close handler (and on dispose/navigation), call an endpoint to delete the already-uploaded file descriptor/blob if it hasn’t been finalized. This reduces leftovers but won’t cover hard refresh/tab close/network loss—so you still typically want (B) as the safety net.

  ---

  Minimal cleanup code idea (server side)

  Use ABP Blob Storing’s container API to remove orphaned blobs when needed (e.g., in a background worker or explicit cancel endpoint):

  public class MyFileCleanupService : ITransientDependency
  {
      private readonly IBlobContainer<MyFileContainer> _container;
  
      public MyFileCleanupService(IBlobContainer<MyFileContainer> container)
      {
          _container = container;
      }
  
      public Task DeleteAsync(string blobName)
      {
          return _container.DeleteAsync(blobName);
      }
  }
  

  You’d combine this with whatever “temporary” tracking you use (DB table/flag, naming convention, etc.) to find candidates to delete.

  ---

  References (verified)

  • https://docs.abp.io/en/abp/latest/Blob-Storing
  • https://abp.io/community/articles/d01cbe12
  • https://abp.io/community/articles/sr7t3w4p

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel
• 

  0

  chrisalves created 8 hours ago

  Hi ABP Folks,

  I´d like to get an architect guy guidance instead of bot answer to be as close as possible of the ABP solution evolution.

  Save Cancel