[Copilot]

This PR adds a failing test to reproduce the bug where a single filter with multiple joins to the same table uses the wrong association alias.

Issue Description

When using Ransack with multiple joins to the same table and applying a filter to only one of the joined associations, the generated SQL uses the wrong table alias in the WHERE clause.

Problem Example

Consider this query:

Recommendation.joins(:person, :target_person).ransack(
  { target_person_name_eq: 'Test' }
).result

Current (incorrect) behavior:

SELECT recommendations.* FROM recommendations
INNER JOIN people ON people.id = recommendations.person_id
INNER JOIN people target_people_recommendations 
  ON target_people_recommendations.id = recommendations.target_person_id
WHERE people.name = 'Test'  -- ❌ Wrong! Uses first join alias

Expected (correct) behavior:

SELECT recommendations.* FROM recommendations
INNER JOIN people ON people.id = recommendations.person_id
INNER JOIN people target_people_recommendations 
  ON target_people_recommendations.id = recommendations.target_person_id
WHERE target_people_recommendations.name = 'Test'  -- ✅ Correct alias

What This PR Does

This PR adds a failing test case that demonstrates the bug. The test:

• Uses the exact pattern that triggers the issue: Recommendation.joins(:person, :target_person).ransack({target_person_name_eq: 'Test'})
• Expects the correct SQL with proper table alias usage
• Will fail until the underlying bug is fixed
• Follows existing test patterns and structure in the codebase

Impact

This bug affects queries where:

1. Multiple associations join to the same table
2. Only one of the associations is filtered
3. The filtered association is not the first one in the join order

The bug can cause incorrect query results by filtering on the wrong table alias.

Note

This PR intentionally does not include a fix - it only adds the failing test case to reproduce the issue and serve as a specification for the expected behavior.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Single filter with multiple joins use the wrong association alias</issue_title>
<issue_description>I wrote this failing spec:

      it 'evaluates single condition for multiple `belongs_to` associations to the same table' do
        # Why Search.new(Recommendation.joins(:person, :target_person)...) is not the same thing?
        s = Recommendation.joins(:person, :target_person).ransack(
          { target_person_name_eq: 'Test' },
        ).result

        expect(s).to be_an ActiveRecord::Relation

        real_query = remove_quotes_and_backticks(s.to_sql)
        expected_query = <<-SQL
          SELECT recommendations.* FROM recommendations
          INNER JOIN people ON people.id = recommendations.person_id
          INNER JOIN people target_people_recommendations
            ON target_people_recommendations.id = recommendations.target_person_id
          WHERE target_people_recommendations.name = 'Test'
        SQL
        .squish

        expect(real_query).to eq expected_query
      end

It results in:

WHERE people.name = 'Test'"

Instead of:

WHERE target_people_recommendations.name = 'Test'"

And it only happens if there isn't a filter on the other table, If I write what the existing spec is testing:

s = Recommendation.joins(:person, :target_person).ransack(
  { person_name_eq: 'Ernie', target_person_name_eq: 'Test' },
).result

Then it works as expected:

WHERE (people.name = 'Ernie' AND target_people_recommendations.name = 'Test')"

This looks like a bug to me, I have one query that I need to join the same table twice, and this is getting the wrong results. I'm joining both tables because I'm selecting specific columns from both tables, but I need to filter by the aliased one.
</issue_description>

<agent_instructions>Please create a PR with this failing test, do not fix</agent_instructions>

Comments on the Issue (you are @copilot in this section)

---- **Additional instructions:**

Please create a PR with this failing test, do not fix

Fixes #1554

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[scarroll32]

Note

Comment from Claude (Claude Code), acting on behalf of @scarroll32.

Closing as part of clearing the PR backlog ahead of 5.0.0 (#1640).

This is one of a batch of PRs opened by the Copilot coding agent in September 2025. They have aged out: main has moved on substantially since (Rails 8.1 support, the CI matrix rework in #1667, the v5.0.0 branch consolidation in #1647), and most of these either no longer apply cleanly, no longer pass, or carry specs that don't run under the project's _spec.rb pattern.

The underlying issue stays open. Nothing is being dismissed on the merits — the bug reports behind these PRs are still valid and still wanted. What's being retired is a batch of stale machine-generated branches that cost more to salvage than to redo.

If you're affected by the underlying issue, the most useful contribution is a PR with a failing spec that reproduces it against current main — see CONTRIBUTING.md.