Bug: Multiple filters cause 500 error - Turbo Frame ID collision

[estevao]

Environment: Self-hosted with SQLite (latest main branch via Docker)

Issue:
Applying a second filter to cards causes a 500 "Content not found" error. First filter works fine, second filter crashes the app consistently.

Steps to Reproduce:

1. Filter cards by any term (e.g., "Install")
2. Apply a second filter (e.g., "Fizzy")
3. App crashes with 500 error

Stack Trace:
[bdba1dfa-a285-4ef1-8862-96ac548db6fb]
[bdba1dfa-a285-4ef1-8862-96ac548db6fb] app/views/cards/display/_previews.html.erb:1
[bdba1dfa-a285-4ef1-8862-96ac548db6fb] app/views/cards/index.html.erb:24
[bdba1dfa-a285-4ef1-8862-96ac548db6fb] app/helpers/pagination_helper.rb:43:in 'block (2 levels) in PaginationHelper#with_automatic_pagination'
[bdba1dfa-a285-4ef1-8862-96ac548db6fb] app/helpers/pagination_helper.rb:68:in 'Kernel#public_send'
[bdba1dfa-a285-4ef1-8862-96ac548db6fb] app/helpers/pagination_helper.rb:68:in 'PaginationHelper#pagination_list'
[bdba1dfa-a285-4ef1-8862-96ac548db6fb] app/helpers/pagination_helper.rb:41:in 'PaginationHelper#with_automatic_pagination'
Request: GET /0000001/cards?terms[]=open&terms[]=configure&sorted_by=latest&indexed_by=all
Status: 500

Root Cause:
pagination_frame_id_for() generates the same Turbo Frame ID regardless of filter params:

• Filter "Install" → cards_paginated_container-pagination-contents-1
• Filter "Fizzy" → cards_paginated_container-pagination-contents-1 (same ID, different content)

Turbo sees identical frame IDs with different contexts and fails.

Note: This works correctly on fizzy.do (SaaS version), suggesting the issue might be related to SQLite queries.

[estevao]

Quick follow up on the filter bug in self-hosted SQLite:

Root cause:
When applying a second filter (e.g. terms[]=open&terms[]=configure), the query joins search_records_fts twice (once per term), causing SQLite to throw: SQLite3::SQLException: ambiguous column name: search_records_fts

This crashes with 500 on page load. First filter (single term) works fine.

Fix:

• In app/models/search/record/sqlite.rb, use a unique alias for each join to avoid ambiguity.
• In app/helpers/pagination_helper.rb, replace params.permit!.to_h with params.permit(Filter::PERMITTED_PARAMS).to_h.merge(page: page_number) to preserve filter params across pagination (prevents Turbo frame confusion).

Updated code:

# app/models/search/record/sqlite.rb
scope :matching, ->(query, account_id) {
  joins("INNER JOIN search_records_fts ON search_records_fts.rowid = #{table_name}.id")
    .where("search_records_fts MATCH ?", query)
}

# app/helpers/pagination_helper.rb (relevant part)
pagination_params = params.permit(Filter::PERMITTED_PARAMS).to_h.merge(page: page_number, **url_params)
link_to label, url_for(pagination_params), ...

Tested locally (SQLite):
Apply first and then second search filter > pagination works, no 500, filters preserved.
This also fixes multi-term search crashes.

Compatibility note:
This should work fine on MySQL/PostgreSQL too - the changes are pure Rails (strong params + alias handling) and MySQL/PostgreSQL handle multi-term FTS joins cleanly without the SQLite alias ambiguity.

[peterb]

I can reproduce this on the current main. I've applied the fix suggested above and added a test. Happy to open a PR if useful: fix-sqlite-multi-term-search.

[flavorjones]

@peterb Please do open a pull request, especially if you've introduced missing test coverage.

[flavorjones]

Ah - looks like you already did! #2688 I'll review as soon as I get a chance.

[peterb]

Awesome.