Fix bot debate outcome update filtering on wrong field

[shwetd19]

Fixes #395

UpdateDebateVsBotOutcome filtered on a userId field while being passed an email, and the documents store it under email — so the update matched nothing. It now filters on email, targets the most recent debate (sorted by createdAt), and the caller logs the error instead of silently discarding it.

[coderabbitai]

Warning

Review limit reached

@shwetd19, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 55 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 55ad5070-a154-41f0-b52e-e2d7e61bf042

📥 Commits

Reviewing files that changed from the base of the PR and between 51532ff and de4f136.

📒 Files selected for processing (2)

• backend/controllers/debatevsbot_controller.go
• backend/db/db.go

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gitcordapp]

Link your account with Gitcord

Thanks for opening this PR, @shwetd19!

To receive Discord notifications and contributor tracking for this organization:

1. Join Discord: https://discord.gg/hjUhu33uAn
2. In Discord, run /link shwetd19
3. Paste the verification code into your GitHub bio (or a public gist)
4. Click Verify in Discord (or run /verify-link shwetd19)

Once linked, Gitcord can notify you about reviews, merges, and more.

— Posted by Gitcord

[Ri1tik]

Can you please attach the current and expected behavior on this. There is merge conflict that need to be resolved. Do as soon as possible.

[shwetd19]

Hey @Ri1tik

The bug here is in the data layer rather than the UI, so the screen looks identical either way. The clearest evidence is the field mismatch itself:

Bot debates are stored with an email field; the model has no userId field at all (backend/models/debatevsbot.go):

type DebateVsBot struct {
    ID    primitive.ObjectID `json:"id" bson:"_id,omitempty"`
    Email string             `json:"email" bson:"email"`
    ...
    Outcome   string `json:"outcome" bson:"outcome"`
    CreatedAt int64  `json:"createdAt" bson:"createdAt"`
}

However, on main, UpdateDebateVsBotOutcome filters with bson.M{"userId": userId}. Since no document contains a userId field, UpdateOne matches 0 documents every time, returns no error, and the outcome is never persisted. The caller in JudgeDebate also discarded the error, so nothing surfaced in the logs.

You can confirm this against any populated DB:

db.debates_vs_bot.find({userId: {$exists: true}})

returns nothing, while every document has email.

The fix filters by email and sorts by createdAt descending, ensuring only the latest debate is updated. The previous unsorted update could have modified an arbitrary debate even if the filter had matched. The error is also now logged instead of being silently swallowed.

Happy to add a before/after mongosh screenshot showing the outcome field on a debate document if runtime confirmation would be helpful.