Fix raid leaderboard submission validity check

[dewabisma]

Summary

• There is a bug where every submission is flagged as invalid because we compare the wrong id. The raider_id in database is quan address and the tweet author_id is x user id. Now it's fixed to compare by username.
• Also remove eligibility check in create raid submission to not block android user from inputting link with redirect, e.g. https://x.com/i/status/2014249207293521979

[n13]

PR Review: Fix raid leaderboard submission validity check (PR #56)

Summary

This PR addresses a critical bug in the raid leaderboard validation logic where submissions were incorrectly flagged as invalid due to mismatched ID types (Quan address vs. X User ID). It also improves the submission UX by relaxing the initial URL validation to support redirected links (e.g., from mobile).

Key Changes

• Validation Logic: Switched from comparing IDs to comparing X usernames. This resolves the issue where raider_id (Quan address) was being compared to tweet.author_id (X numeric ID).
• Database Query: Updated find_valid_only_by_raid to LEFT JOIN with x_associations, efficiently fetching the raider's username alongside the submission.
• Submission Handler: Removed the strict username check at submission time. This allows the background worker to handle the validation, enabling support for shortened or redirected URLs.
• Twitter API: Added TweetExpansion::AuthorId to fetch author details in the batch request.

Suggestions & Observations

1. Robustness of LEFT JOIN in Repository

In src/repositories/raid_submission.rs, the query uses a LEFT JOIN:

SELECT rs.id as raid_submission_id, x.username as raider_username 
FROM raid_submissions rs 
LEFT JOIN x_associations x ON rs.raider_id = x.quan_address

And maps it to:

pub struct ValidRaidSubmissionWithRaiderUsername {
    pub raid_submission_id: String,
    pub raider_username: String, // Expects non-null
}

Risk: If a user unlinks their X account (removing the row from x_associations) after submitting but before the leaderboard sync runs, the LEFT JOIN will return NULL for raider_username. This will cause sqlx to fail deserialization for the entire batch, potentially stalling the leaderboard sync.

Recommendation:

• Option A (Stricter): Use INNER JOIN. This ensures we only fetch submissions where the user currently has a linked X account. If they unlinked, they are simply skipped in the leaderboard check.
• Option B (More Graceful): Change raider_username to Option<String> in the struct and handle the None case in the service (e.g., treat as invalid or skip).

2. Case Sensitivity

The use of eq_ignore_ascii_case in src/services/raid_leaderboard_service.rs is excellent practice for username comparisons.

Conclusion

The logic changes are sound and address the reported issues effectively. The shift to username validation is the correct approach here. Addressing the potential NULL issue in the repository query would make the sync process more resilient to edge cases.

Status: Approved with suggestions.

[n13]

I think this needs to be fixed (or if it is a non-issue dismissed)

[dewabisma]

Thanks, it was a very good edge case that likely to happen. I overlooked that.

[n13]

LGTM