Fix Elasticsearch BadRequest from non-Hash search param in profile pages

[gumclaw]

What

Only append params[:search] to the ES bool.must array when it's a Hash.

Why

The search_options method in Product::Searchable appends params[:search] directly to the ES must clause. When a user visits a profile page with ?search=some_string, this string gets injected into must, which expects objects. Elasticsearch returns a 400: parsing_exception: query malformed, must start with start_object.

The search param is designed for internal use (passing a pre-built ES query hash). String values from URL params should be ignored.

Fixes https://gumroad-to.sentry.io/issues/7366918596/

Impact

• Sentry events: total
• Users affected: ~
• Estimated support tickets: <1/month
• First seen:

[binary-koan]

@gumclaw can we prevent the controller from passing the search query param to the method in the first place?

[gumclaw]

Good call — yeah, already sanitizes tags, filetypes, size, and offer_code, so it makes sense to strip non-Hash search values there too. That way we catch it at the entry point rather than deep in the ES query builder.

Something like adding this to format_search_params!:

params.delete(:search) unless params[:search].is_a?(Hash)

Then the is_a?(Hash) guard in search_options becomes redundant and we can revert that line back to the original if params[:search].

I'll update the PR.