fix: full_up_scan didn't reach rank 1 when own rank is close to the top #8

Merged

DasAoD merged 1 commit from fix/full-up-scan-low-rank-window into main

2026-09-21 20:07:45 +02:00

DasAoD commented

2026-09-21 20:07:17 +02:00

Owner

Bug

Reported at rank #62: with "Komplette Ehrenhalle bis Rang 1" checked, both the results table and the "Vollständige Ehrenhalle" view stopped at rank #42 instead of reaching #1 — and every entry shown was marked "Angreifbar: Ja", which should be impossible for a real full-ladder scan.

Root cause

rank_up_start = own_rank - 20. When that value is small enough (<= 51), page_low becomes 0, meaning the mandatory-window pages (Phase 1a) already include page 0 — which covers ranks 1-51. But Phase 1a's in_rank_window filter was hardcoded to [rank_up_start, rank_down_end] regardless of full_up_scan, so the already-fetched ranks 1 through rank_up_start - 1 got discarded before ever reaching all_hof_guilds. The separate extension phase meant to handle "scan further up" never ran either, since it's guarded by page_low > 0 — there was nothing left to extend, the gap was purely in the filter on data already in hand.

This only affects accounts whose rank is close enough to #1 that rank_up_start <= 51 (roughly rank ≤ 71 with the default 20-rank window). At larger ranks (e.g. #2102, tested earlier) the separate extension phase already handles it correctly.

Fix

in_rank_window now widens to rank <= rank_down_end (any rank above, down through the down-limit) when full_up_scan is set, instead of being clamped to rank_up_start.

Test

cargo build --all-targets compiles without warnings. Real-world verification (re-running a scan at rank #62 with "Komplette Ehrenhalle bis Rang 1" checked, confirming it now reaches #1 with a mix of Ja/Nein attackable badges) still needs to happen after deploy.

🤖 Generated with Claude Code

## Bug Reported at rank #62: with "Komplette Ehrenhalle bis Rang 1" checked, both the results table and the "Vollständige Ehrenhalle" view stopped at rank #42 instead of reaching #1 — and every entry shown was marked "Angreifbar: Ja", which should be impossible for a real full-ladder scan. ## Root cause `rank_up_start = own_rank - 20`. When that value is small enough (`<= 51`), `page_low` becomes `0`, meaning the mandatory-window pages (Phase 1a) already include page 0 — which covers ranks 1-51. But Phase 1a's `in_rank_window` filter was hardcoded to `[rank_up_start, rank_down_end]` regardless of `full_up_scan`, so the already-fetched ranks 1 through `rank_up_start - 1` got discarded before ever reaching `all_hof_guilds`. The separate extension phase meant to handle "scan further up" never ran either, since it's guarded by `page_low > 0` — there was nothing left to extend, the gap was purely in the filter on data already in hand. This only affects accounts whose rank is close enough to #1 that `rank_up_start <= 51` (roughly rank ≤ 71 with the default 20-rank window). At larger ranks (e.g. #2102, tested earlier) the separate extension phase already handles it correctly. ## Fix `in_rank_window` now widens to `rank <= rank_down_end` (any rank above, down through the down-limit) when `full_up_scan` is set, instead of being clamped to `rank_up_start`. ## Test `cargo build --all-targets` compiles without warnings. Real-world verification (re-running a scan at rank #62 with "Komplette Ehrenhalle bis Rang 1" checked, confirming it now reaches #1 with a mix of Ja/Nein attackable badges) still needs to happen after deploy. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

DasAoD added 1 commit

2026-09-21 20:07:17 +02:00

main.rs: fix full_up_scan not reaching ranks above the mandatory window when own rank is close to #1 9c768f3b10

- in_rank_window was hardcoded to [rank_up_start, rank_down_end] regardless of full_up_scan, so guilds already fetched via the mandatory-window pages got filtered out before ever reaching all_hof_guilds
- only affected accounts where rank_up_start <= 51 (page_low == 0), since the separate honor-up-scan/full_up_scan extension phase is guarded by page_low > 0 and never runs in that case, even though page 0 (ranks 1-51) was already fetched
- full_up_scan now widens the filter to any rank <= rank_down_end, fixing the case reported at rank #62 (results/full HoF view stopped at #42 instead of reaching #1)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

DasAoD merged commit c4f6dd7135 into main

2026-09-21 20:07:45 +02:00

DasAoD referenced this pull request from a commit

2026-09-21 20:07:47 +02:00

Merge pull request 'fix: full_up_scan didn't reach rank 1 when own rank is close to the top' (#8) from fix/full-up-scan-low-rank-window into main