What causes "InstFS file deletion failed for attachment #{id}: #{e.message}" in instructure/canvas-lms?

Check InstFS service health and connectivity from Canvas (instfs host config, shared JWT secret)

InstFS file deletion failed for attachment #

Error message

InstFS file deletion failed for attachment #{id}: #{e.message}

What it means

When destroying an Attachment hosted in InstFS, Canvas calls InstFS.delete_file; if that raises InstFS::DeletionError, the error is logged with the attachment id and message, and deletion of the DB record proceeds with instfs_uuid cleared — the orphaned InstFS file may remain in storage.

Solutions

Check InstFS service health and connectivity from Canvas (instfs host config, shared JWT secret)
Verify the uuid still exists in InstFS — already-deleted files may raise DeletionError
Retry after InstFS recovers, or manually clean the orphaned object in InstFS storage
Note the record is still destroyed and instfs_uuid nil'ed; only orphan cleanup is impacted

Example fix

// before
InstFS.delete_file(instfs_uuid)
// after
begin
  InstFS.delete_file(instfs_uuid)
rescue InstFS::DeletionError => e
  Rails.logger.warn("InstFS file deletion failed for attachment #{id}: #{e.message}")
  # optionally enqueue a retry for orphan cleanup
end

Defensive patterns

Strategy: try-catch

Validate before calling

if attachment.instfs_hosted? && attachment.instfs_uuid.present?
  # proceed with InstFS delete path
end

Type guard

def deletable_attachment?(att)
  att.persisted? && att.instfs_hosted? && att.instfs_uuid.present?
end

Try / catch

begin
  InstFS.delete_file(instfs_uuid)
rescue InstFS::DeletionError => e
  Rails.logger.warn("InstFS deletion failed for #{instfs_uuid}: #{e.message}")
  # enqueue retry for orphan cleanup
end

Prevention

Monitor InstFS service health and alert on outages
Make deletion idempotent — tolerate already-deleted UUIDs
Queue retry jobs for failed deletions instead of relying only on the log
Verify instfs host and JWT secret config match between Canvas and InstFS

When it happens

Trigger: Destroying an attachment whose instfs_hosted? is true when InstFS.delete_file fails: InstFS service unreachable, uuid already deleted, or the service returning an error response.

Common situations: InstFS down or misconfigured (host/JWT secret mismatch between Canvas and InstFS); duplicate destroy attempts where the UUID was already removed; network partition between Canvas and InstFS.

Related errors

AI-assisted analysis of instructure/canvas-lms@1c9f0bb801 (2026-09-15). Data as JSON: /api/errors/55f33386ee4e0a30. Report an issue: GitHub.

Appendix: source

Thrown at app/models/attachment.rb:2005

    end
    save! if changed?
    p.workflow_state = "restored"
    p.save!
  end

  def dmca_file_removal
    destroy_content_and_replace
  end

  def destroy_content
    raise "must be a root_attachment" if root_attachment_id
    return unless filename

    if instfs_hosted?
      begin
        InstFS.delete_file(instfs_uuid)
      rescue InstFS::DeletionError => e
        Rails.logger.warn("InstFS file deletion failed for attachment #{id}: #{e.message}")
      end
      self.instfs_uuid = nil
    elsif Attachment.s3_storage?
      s3object.delete unless ApplicationController.test_cluster?
    else
      FileUtils.rm_f(full_filename)
    end
  end

  def destroy_permanently_plus
    unless root_attachment_id
      make_childless
      destroy_content
    end
    destroy_permanently!
  end

  def make_childless(preferred_child = nil)

View on GitHub (pinned to 1c9f0bb801)