teamcapybara/capybara · warning

'find' does not support count options (#{count_options}) ign

Error message

'find' does not support count options (#{count_options}) ignoring. Called from: #{Capybara::Helpers.filter_backtrace(caller)}

What it means

find resolves exactly one element and returns it, so the count constraints :count, :minimum, :maximum and :between (Capybara::Queries::BaseQuery::COUNT_KEYS) are meaningless there. When any of them is passed, Capybara emits this warning, strips/ignores the count options, and runs the query anyway; the count has no effect on the result.

Source

Thrown at lib/capybara/node/finders.rb:55

      #   @option options [String, Regexp]  id           Only find elements with an id that matches the value passed
      #   @option options [String, Array<String>, Regexp] class  Only find elements with matching class/classes.
      #                                            * Absence of a class can be checked by prefixing the class name with `!`
      #                                            * If you need to check for existence of a class name that starts with `!` then prefix with `!!`
      #
      #                                                class:['a', '!b', '!!!c'] # limit to elements with class 'a' and '!c' but not class 'b'
      #
      #   @option options [String, Regexp, Hash] style  Only find elements with matching style. String and Regexp will be checked against text of the elements `style` attribute, while a Hash will be compared against the elements full style
      #   @option options [Boolean] exact            Control whether `is` expressions in the given XPath match exactly or partially. Defaults to {Capybara.configure exact}.
      #   @option options [Symbol] match        The matching strategy to use. Defaults to {Capybara.configure match}.
      #
      # @return [Capybara::Node::Element]      The found element
      # @raise  [Capybara::ElementNotFound]    If the element can't be found before time expires
      #
      def find(*args, **options, &optional_filter_block)
        options[:session_options] = session_options
        count_options = options.slice(*Capybara::Queries::BaseQuery::COUNT_KEYS)
        unless count_options.empty?
          Capybara::Helpers.warn(
            "'find' does not support count options (#{count_options}) ignoring. " \
            "Called from: #{Capybara::Helpers.filter_backtrace(caller)}"
          )
        end
        synced_resolve Capybara::Queries::SelectorQuery.new(*args, **options, &optional_filter_block)
      end

      ##
      #
      # Find an {Capybara::Node::Element} based on the given arguments that is also an ancestor of the element called on.
      # {#ancestor} will raise an error if the element is not found.
      #
      # {#ancestor} takes the same options as {#find}.
      #
      #     element.ancestor('#foo').find('.bar')
      #     element.ancestor(:xpath, './/div[contains(., "bar")]')
      #     element.ancestor('ul', text: 'Quox').click_link('Delete')
      #

View on GitHub (pinned to 15b5fdb76e)

Solutions

1. Assert counts with a matcher: expect(page).to have_selector('.item', count: 3).
2. If you only need an element, drop the count option from find entirely.
3. If you need the collection, use all('.item') / find_all('.item'), where count options are honored.

Example fix

# before
page.find('.items .item', count: 3) # warns; count ignored

# after
expect(page).to have_selector('.items .item', count: 3)

COUNT_KEYS = %i[count minimum maximum between].freeze

# Before calling find with a dynamic options hash:
find_options = options.except(*COUNT_KEYS)
if (options.keys & COUNT_KEYS).any?
  warn "Moving count options #{options.slice(*COUNT_KEYS)} to a matcher"
  expect(page).to have_selector(selector, **options.slice(*COUNT_KEYS))
end
find(selector, **find_options)

def find_options?(opts)
  (opts.keys & %i[count minimum maximum between]).empty?
end

When it happens

Trigger: page.find('.items .item', count: 3); find('tr', minimum: 1); copying an options hash from have_selector('.item', count: 2) or all('li', maximum: 5) into a find call.

Common situations: Developer intends to assert how many elements exist but uses the single-element finder; refactoring between all/find leaves stale options; shared option hashes reused across finders and matchers, producing noisy warnings in CI logs.

Related errors

• Boolean 'exact_text' option is not supported when 'text' opt
• Locator #{locator.class}:#{locator.inspect} for selector #{n
• Invalid option #{match.inspect} for :match, should be one of
• Invalid option(s) #{invalid_names}, should be one of #{valid
• #{@type} is not a valid type for a text query

AI-assisted analysis of teamcapybara/capybara@15b5fdb76e (2026-08-21). Data as JSON: /api/errors/940c80fd3d3d03eb. Report an issue: GitHub.