carrierwaveuploader/carrierwave · error · CarrierWave::IntegrityError

errors.messages.max_width_error

Error message

errors.messages.max_width_error

What it means

Raised as CarrierWave::IntegrityError when check_dimensions! sees an image wider than the upper bound of width_range (message errors.messages.max_width_error, bound formatted with thousands delimiters). It is checked only for the base version and only when the uploader has width/height methods from CarrierWave::MiniMagick, RMagick, or Vips; the elsif chain means width bounds are evaluated before height bounds.

Source

Thrown at lib/carrierwave/uploader/dimension.rb:56

      #     end
      #
      def height_range; end

    private

      def check_dimensions!(new_file)
        # NOTE: Skip the check for resized images
        return if version_name.present?
        return unless width_range || height_range

        unless respond_to?(:width) || respond_to?(:height)
          raise 'You need to include one of CarrierWave::MiniMagick, CarrierWave::RMagick, or CarrierWave::Vips to perform image dimension validation'
        end

        if width_range&.begin && width < width_range.begin
          raise CarrierWave::IntegrityError, I18n.translate(:"errors.messages.min_width_error", :min_width => ActiveSupport::NumberHelper.number_to_delimited(width_range.begin))
        elsif width_range&.end && width > width_range.end
          raise CarrierWave::IntegrityError, I18n.translate(:"errors.messages.max_width_error", :max_width => ActiveSupport::NumberHelper.number_to_delimited(width_range.end))
        elsif height_range&.begin && height < height_range.begin
          raise CarrierWave::IntegrityError, I18n.translate(:"errors.messages.min_height_error", :min_height => ActiveSupport::NumberHelper.number_to_delimited(height_range.begin))
        elsif height_range&.end && height > height_range.end
          raise CarrierWave::IntegrityError, I18n.translate(:"errors.messages.max_height_error", :max_height => ActiveSupport::NumberHelper.number_to_delimited(height_range.end))
        end
      end

    end # Dimension
  end # Uploader
end # CarrierWave

View on GitHub (pinned to b5f0abe10e)

Solutions

  1. Raise the upper bound to fit real inputs (width_range 100..5000), or set it explicitly per uploader
  2. Downscale on upload instead of rejecting: process resize_to_limit: [1600, 1600] and relax the range (processing runs on versions, base check uses the original — consider resizing before validation or capping client-side)
  3. Rescue CarrierWave::IntegrityError and surface a clear 'image too wide, max X px' message
  4. Validate dimensions in the client/upload widget before the POST

Example fix

# before
class PhotoUploader < CarrierWave::Uploader::Base
  include CarrierWave::MiniMagick
  width_range 800..1600 # 4000px photo -> IntegrityError max_width_error
end

# after
class PhotoUploader < CarrierWave::Uploader::Base
  include CarrierWave::MiniMagick
  process resize_to_limit: [1600, nil]
  width_range 100..4000
end
Defensive patterns

Strategy: validation

Validate before calling

require 'fastimage'

MAX_W = 1600
w, _h = FastImage.size(params[:image].path)
return render_error(:too_wide) if w && w > MAX_W

Type guard

def within_width_range?(path, range)
  w, = FastImage.size(path)
  !w.nil? && (range.begin.nil? || w >= range.begin) && (range.end.nil? || w <= range.end)
end

Try / catch

begin
  record.save!
rescue CarrierWave::IntegrityError => e
  record.errors.add(:image, :dimensions_invalid, message: e.message)
  render :new
end

Prevention

When it happens

Trigger: Declaring width_range 800..1600 and uploading a 3000px-wide panorama or full-resolution photo; large exports from design tools exceeding the configured maximum.

Common situations: Servers rejecting modern camera/phone photos (often 4000px+); width limits added to protect processing memory but users' originals exceed them; maximums tuned for one feature (avatars) accidentally applied to another uploader via copy-paste.

Related errors


AI-assisted analysis of carrierwaveuploader/carrierwave@b5f0abe10e (2026-08-21). Data as JSON: /api/errors/98d2f989b3f831ce. Report an issue: GitHub.