fix(indexer): restore dense-competitive RANK on referrer leaderboard (GitLab #204) #390

2026-05-15T03:08:11Z

Brouie commented

2026-05-15 03:08:11 +00:00

(Migrated from gitlab.com)

Closes by fixing the regression flagged in #204 note 3350384677.

What this changes

Removes the r.referrer ASC tiebreaker from the RANK() OVER (ORDER BY ...) window in indexer/src/api.rs:1921. The outer ORDER BY rank ASC, referrer ASC is unchanged — tiebreaker semantics for result ordering are preserved.

                         RANK() OVER (
-                            ORDER BY COALESCE(a.total_charm, 0) DESC NULLS LAST, r.referrer ASC
+                            ORDER BY COALESCE(a.total_charm, 0) DESC NULLS LAST
                         )::bigint AS rank

Root cause

With both total_charm DESC and r.referrer ASC inside the same window ORDER BY, RANK() only ties rows when BOTH columns match. Since every referrer is distinct, no two rows ever tie and RANK() degrades to page-ordinal (1, 2, 3, 4) — breaking INV-INDEXER-170-REFERRAL-LB-TIE (dense-competitive 1, 2, 2, 4 pattern from #177).

Pre-#204 fix in commit 6d92cc4 had the dense-competitive behavior; #204's SQL rewrite (commit a57d0d96) regressed it.

Verification

Dense-rank test passes on fresh ephemeral DB:

cd indexer && YIELDOMEGA_PG_TEST_URL="postgres://yieldomega:password@127.0.0.1:5433/yieldomega_test_204" cargo test --release postgres_gitlab177_referrer_leaderboard_dense_rank

test postgres_gitlab177_referrer_leaderboard_dense_rank ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 3 filtered out

Item 1 still passes on prod-shaped data: local stack indexer rebuilt with the patch, indexer DB wiped + reingested from anvil block 0, leaderboard endpoint returns the two real wallets with correct ranks 1 and 2:

{"items":[
  {"codes_registered_count":"1","rank":1,"referred_buy_count":"21310","referrer":"0x87bdce72...","total_referrer_charm_wad":"5806311832977428474529"},
  {"codes_registered_count":"1","rank":2,"referred_buy_count":"0","referrer":"0xdf37f81daad2b0327a0a50003740e1c935c70913","total_referrer_charm_wad":"0"}
]}

x-schema-version: 1.19.0 header confirmed.

Item 2 walked on laptop frontend pointed at the patched indexer. /referrals Guide leaderboard renders both wallets with correct onchain codes registered + recorded buys sublines. Summary tiles show Codes registered: 2, Recorded referral buys: 21,354, Total guide CHARM: 5.82K. The code-only wallet (0xdf37f81d...) appears with rank 2 and 0 recorded buys with this referrer code — matching the empty-state copy spec.

Items not covered by this MR

Item 3 (CHARM moves while registration counts stay consistent after a new buy lands): blocked pre-launch — ReferralApplied won't emit on prod TimeCurve until sale opens. No way to walk without real chain activity.
Items 1, 2, 4, 5 all PASS with this fix applied. Item 4 going from RED to GREEN is the new signal from this MR.

Out of scope

This MR is narrow: rank SQL only. No frontend changes, no schema changes, no doc changes, no migration. The #204 union logic + codes_registered_count field continue to work as designed.

Closes by fixing the regression flagged in #204 note 3350384677. ## What this changes Removes the `r.referrer ASC` tiebreaker from the `RANK() OVER (ORDER BY ...)` window in `indexer/src/api.rs:1921`. The outer `ORDER BY rank ASC, referrer ASC` is unchanged — tiebreaker semantics for result ordering are preserved. ```diff RANK() OVER ( - ORDER BY COALESCE(a.total_charm, 0) DESC NULLS LAST, r.referrer ASC + ORDER BY COALESCE(a.total_charm, 0) DESC NULLS LAST )::bigint AS rank ``` ## Root cause With both `total_charm DESC` and `r.referrer ASC` inside the same window `ORDER BY`, `RANK()` only ties rows when BOTH columns match. Since every referrer is distinct, no two rows ever tie and `RANK()` degrades to page-ordinal (`1, 2, 3, 4`) — breaking `INV-INDEXER-170-REFERRAL-LB-TIE` (dense-competitive `1, 2, 2, 4` pattern from #177). Pre-#204 fix in commit `6d92cc4` had the dense-competitive behavior; #204's SQL rewrite (commit `a57d0d96`) regressed it. ## Verification **Dense-rank test passes on fresh ephemeral DB:** ``` cd indexer && YIELDOMEGA_PG_TEST_URL="postgres://yieldomega:password@127.0.0.1:5433/yieldomega_test_204" cargo test --release postgres_gitlab177_referrer_leaderboard_dense_rank test postgres_gitlab177_referrer_leaderboard_dense_rank ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 3 filtered out ``` **Item 1 still passes on prod-shaped data:** local stack indexer rebuilt with the patch, indexer DB wiped + reingested from anvil block 0, leaderboard endpoint returns the two real wallets with correct ranks 1 and 2: ```json {"items":[ {"codes_registered_count":"1","rank":1,"referred_buy_count":"21310","referrer":"0x87bdce72...","total_referrer_charm_wad":"5806311832977428474529"}, {"codes_registered_count":"1","rank":2,"referred_buy_count":"0","referrer":"0xdf37f81daad2b0327a0a50003740e1c935c70913","total_referrer_charm_wad":"0"} ]} ``` `x-schema-version: 1.19.0` header confirmed. **Item 2 walked on laptop frontend pointed at the patched indexer.** `/referrals` Guide leaderboard renders both wallets with correct `onchain codes registered` + `recorded buys` sublines. Summary tiles show `Codes registered: 2`, `Recorded referral buys: 21,354`, `Total guide CHARM: 5.82K`. The code-only wallet (`0xdf37f81d...`) appears with rank 2 and `0 recorded buys with this referrer code` — matching the empty-state copy spec. ## Items not covered by this MR - **Item 3** (CHARM moves while registration counts stay consistent after a new buy lands): blocked pre-launch — `ReferralApplied` won't emit on prod TimeCurve until sale opens. No way to walk without real chain activity. - Items 1, 2, 4, 5 all PASS with this fix applied. Item 4 going from RED to GREEN is the new signal from this MR. ## Out of scope This MR is narrow: rank SQL only. No frontend changes, no schema changes, no doc changes, no migration. The #204 union logic + `codes_registered_count` field continue to work as designed.

PlasticDigits (Migrated from gitlab.com) merged commit b0b5962e9a into main

2026-05-15 06:12:43 +00:00

PlasticDigits commented

2026-05-15 06:12:44 +00:00

(Migrated from gitlab.com)

mentioned in commit b0b5962e9a

mentioned in commit b0b5962e9adc99ced0cd9f6325a1b2f3896f4584

Sign in to join this conversation.

No reviewers

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

code/yieldomega!390

Rows
Columns