Fix vote count hot score calculation inconsistency

[marcodejongh]

Summary

This PR fixes an inconsistency in hot score calculations for vote counts by ensuring the update_vote_counts trigger uses the same fallback logic as the backfill migration.

Key Changes

• Database Migration (0054): Updated the update_vote_counts trigger to use MIN(votes.created_at) as the fallback timestamp instead of NOW() when no existing feed_items row exists. This ensures consistency with the backfill logic in migration 0053.
• Notification Query Fix: Corrected a syntax error in the notifications resolver where an incomplete ORDER B clause was present.
• Hook Cleanup: Minor cleanup in the paginated feed hook.

Implementation Details

The issue occurred because when a previously-backfilled entity received a new vote, the trigger would recalculate the hot_score using the current timestamp (NOW()) instead of preserving the original earliest vote time. This caused hot_score values to be inconsistent depending on whether they were calculated during backfill or during subsequent vote updates. By using MIN(votes.created_at) as the fallback in both places, we ensure deterministic and consistent hot_score calculations across all scenarios.

https://claude.ai/code/session_017BNXBJR7yWabEhFCeKk9Pz

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
boardsesh	Building	Preview, Comment	Feb 13, 2026 1:41pm

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[claude]

Claude Review

⚠️ Needs attention - The 0054_snapshot.json modification raises concerns about migration integrity.

Issues

1. packages/db/drizzle/meta/0054_snapshot.json - Modifying an existing migration snapshot's id, prevId, and removing tables (gym_follows, gym_members, gyms) from a previously-deployed snapshot breaks the migration chain integrity. Snapshots should be immutable once deployed. If these changes reflect a rebase against main, verify the snapshot matches what's actually deployed in production.

2. packages/backend/src/graphql/resolvers/social/notifications.ts:199-206 - The refactored filter logic moves the null check to after the map operation. While functionally equivalent, this creates unnecessary intermediate objects that are immediately discarded. The original pattern (filter before map) was more efficient.

Minor

3. PR description mentions "0054" migration - But the actual migration file is 0056_fix_vote_counts_hot_score_fallback.sql. The description should be updated for clarity.