Support filter by referral code to raid leaderboard endpoint

[dewabisma]

Summary

Now the GET raid leaderboard endpoint properly support filter by referral code

[n13]

Code Review: Feat - Filter by Referral Code

This PR adds the ability to filter the raid leaderboard by a user's referral code. The implementation correctly modifies the repository and handler.

1. Correct Rank Preservation

I really like how you handled the ranking logic in src/repositories/raid_leaderboard.rs.

WITH ranked_entries AS (
    SELECT ..., RANK() OVER (...) as rank
    FROM raid_leaderboards
    WHERE raid_id = $1
)
SELECT ... FROM ranked_entries
JOIN addresses ...
WHERE ...

By calculating the RANK() in the CTE (Common Table Expression) before applying the referral code filter, you ensure that a user's rank (e.g., #5 Global) remains accurate even when looking at a filtered list. If you had filtered first and then ranked, the user would appear as #1 in the filtered list, which would be misleading. Great job here.

2. SQL Injection Protection

The use of QueryBuilder and push_bind for the ILIKE clause is correct and prevents SQL injection.

qb.push(" AND a.referral_code ILIKE ");
qb.push_bind(format!("{}%", code));

3. Join Optimization

In get_total_items, you conditionally join the addresses table only when filtering is active.

if referral_code.is_some() {
    qb.push(" JOIN addresses a ON l.raider_id = a.quan_address ");
}

This is a good optimization to keep the default count query fast.

4. Minor Suggestion: ILIKE Pattern

You are using format!("{}%", code), which is a "starts with" search.

• If the intention is to find an exact referral code match (which is usually unique), strict equality (=) would be faster and more precise.
• If the intention is strictly "starts with" for autocomplete-style searching, then ILIKE is correct. Just be aware that "REF" might match "REF_A", "REF_B", etc.

Summary

The code is clean, optimized, and logic for ranking is handled correctly.
green light to merge.

[n13]

LGTM