Avoid duplicate personal rows in reading leaderboards

[abhi1693]

What changes and why?

When a signed-in reader appeared in a leaderboard's displayed rows, the personal footer rendered the same reader again. Each board now highlights that reader once in the list and omits the duplicate footer and divider. The personal footer remains when their username is outside that board's displayed rows.

Membership is checked independently for longest streak and total reading days, using the username rather than the numerical rank. This preserves personal ranks for ties that extend beyond the ten displayed readers.

Read-only production checks refreshed at 2026-10-04 17:46 UTC found 29 accounts, four claimed public usernames, and ten accounts with recorded reading activity. One account qualifies for both boards: the other nine active readers have no claimed username, and the other three claimed public profiles have no reading activity. Both the live public API and the database return one eligible reader per board. Reading-day and streak projections have zero mismatches and no missing active-reader projection.

The backend already orders each board by its own descending score with a deterministic username tie-break and a ten-row limit. Real PostgreSQL regressions now verify the complete top-ten order and distinct usernames, twelve-way ties at the cutoff, global personal ranks outside the displayed ten, and an active unclaimed reader immediately joining both top tens after claiming a username. Public-profile eligibility remains unchanged.

CI also exposed a reader-test race: rendering could replace a touch target between the actionability preflight and its bounds lookup. Per the requested scope, this PR now retries only touch preparation within a five-second budget, before dispatching native events. A real browser regression forces that remount and checks exactly one touch and one click.

The README now explains leaderboard eligibility and where personal ranks appear. Changes are isolated on fix/leaderboard-own-row.

Validation

Updated against master after #82, preserving query/account boundaries, grid/list preferences, prompt coordination, article-first rendering, filter recovery and scoped touch/runtime fixtures.

• Seven real PostgreSQL leaderboard integration regressions passed, using disposable PostgreSQL 18 and Redis 8 database 15. No production data was changed.
• 27 leaderboard, route, reading-streak and account regressions passed. Cases cover a user present in both boards, a self-only table, ties outside displayed rows, independent membership in each metric, missing data and account changes.
• The shared leaderboard browser helper now lives under apps/web/tests/browser, with the website and Chrome/Edge consumers updated. Application coverage exclusions are unchanged.
• The remount regression fails against the old helper with null target bounds and passes with the fix in both Chromium and Microsoft Edge. No touch events are replayed; no test is skipped or threshold relaxed.
• Normal commit hooks passed for Python checks/full backend unit coverage, frontend lint/types/unit tests, and extension types/tests/builds.
• Current-head CI passed on 702257b8: 39 jobs passed, ten expected skips, including CI required, all CodeQL analyses and SonarQube. 3,007 backend unit, 1,139 PostgreSQL integration, 852 reader and 648 admin tests passed, with no skips. Whole-backend combined coverage is 67.79% across 273 source files, above the unchanged 67.60% minimum.
• Actual web, Chrome and Microsoft Edge browser journeys passed. Both extensions passed all five browser suites, including both remount cases, ten distinct leaderboard rows, independent personal membership and the self-only table. Existing grid/list, 120-article pagination, prompt coordination and article-first journeys passed.
• Fresh Sonar MCP verification after analysis: quality gate OK, 100.0% new-code coverage, 0.0% new duplication, and zero open/confirmed issues. No rules, exclusions, thresholds or quality gates were relaxed. Auto-merge is disabled.
• GitHub's separate managed AI findings scan remains unavailable because its monthly quota is exceeded (HTTP 402); standard CodeQL completed successfully.
• Native GitHub screenshot attachment upload is unavailable through the configured tools. Screenshots were captured and reviewed during the original implementation; refreshed CI screenshots for the website at desktop and 320px were also reviewed; no review images are committed.

Rollout notes

Frontend rendering change only; no API contract or database migration changes. Production was inspected without writes. Website deployment and Chrome/Edge store publication remain pending release.

Merge after #82 and before #84, after all current-head checks pass.

Ready for review

• The description explains the change and validation results, including gaps.
• Relevant usage documentation and regression tests are updated.

[github-actions]

PR reader API performance

Result: INCONCLUSIVE

7 inconclusive · 1 within threshold. Zero request failures across all six runs.

Base ed4bda1b905dad657aabbbfd161bfa8fb5870ce1 → PR 702257b8336dd7bc3688ace31492a7b7b3c0af8c

Three independent runs per revision, each on a fresh GitHub-hosted ARM64 runner. 16 users, 60 seconds/run, 1,000 synthetic articles, cache off, five PgBouncer slots.

Latency comparison

All latency values are in milliseconds; lower is better. Values are medians of three runs.

Route	Base p95	PR p95	Change	Result
All requests	87	100	+13 (+14.9%)	Inconclusive
Latest feed	110	140	+30 (+27.3%)	Inconclusive
Feed pagination	77	100	+23 (+29.9%)	Inconclusive
Article detail	69	72	+3 (+4.3%)	Inconclusive
Source feed	60	87	+27 (+45.0%)	Inconclusive
Topic feed	73	89	+16 (+21.9%)	Inconclusive
Feed filters	61	85	+24 (+39.3%)	Inconclusive
Sources	30	45	+15 (+50.0%)	Within threshold
Topics	40	54	+14 (+35.0%)	Inconclusive

Additional latency and throughput metrics

Each cell shows base → PR. Latencies are in milliseconds.

Endpoint	p50	p99	Requests/s
Aggregated	28 → 30	130 → 150	30.32 → 30.38
/v1/feed [latest]	42 → 46	140 → 170	9.11 → 8.90
/v1/feed [page]	24 → 28	110 → 140	3.63 → 3.80
/v1/articles/[id]	16 → 19	100 → 110	6.54 → 6.26
/v1/feed [source]	27 → 28	120 → 140	2.08 → 1.79
/v1/feed [topic]	26 → 26	100 → 130	1.78 → 1.55
/v1/feed/options	20 → 22	87 → 120	2.38 → 2.61
/v1/sources	11 → 11	33 → 100	2.38 → 2.61
/v1/topics	11 → 14	52 → 91	2.38 → 2.61

Individual runs

Run	Requests	Failures	Exit code
Base 1	1677	0	0
Base 2	1706	0	0
Base 3	1704	0	0
PR 1	1693	0	0
PR 2	1704	0	0
PR 3	1727	0	0

How to interpret this report

Regressed / Improved: a p95 regression needs >20% and >20 ms increase in the medians and at least two head samples versus the base median. Improvements use the inverse threshold. Within threshold means the change did not meet both thresholds.

Inconclusive: a within-revision p95 range >35% of its median and >20 ms is too noisy for a confident latency verdict.

Inconclusive latency comparisons are non-blocking: the check passes without claiming an improvement. Confirmed regressions and test/report errors fail the PR gate. Throughput is descriptive: paced users do not measure maximum capacity. This uncached public API test does not establish production health, browser performance or worker capacity. Separate runners can differ in hardware or host load; repetitions and noise checks reduce but cannot eliminate that uncertainty.

Full HTML/CSV reports and logs · attempt 1

[github-actions]

Backend unit coverage

PASS · minimum combined coverage 67.60%.

Tests: 3007 passed, 0 failed, 0 skipped. Source files: 273.

Workspace	Lines	Branches	Combined
All backend code	71.64%	53.77%	67.79%
apps/admin-api	64.78%	35.76%	59.95%
apps/aggregator	73.60%	57.18%	69.86%
apps/api	68.94%	55.88%	66.48%
apps/article-enrichment-worker	80.00%	50.00%	71.43%
apps/cli	68.76%	42.93%	64.81%
apps/images-worker	80.00%	50.00%	71.43%
apps/mcp	79.90%	73.88%	78.77%
apps/notifications	83.33%	76.67%	81.75%
apps/search-indexer	85.48%	85.71%	85.53%
apps/source-discovery-worker	80.00%	50.00%	71.43%
apps/user-api	59.19%	32.90%	54.27%
packages/core	73.81%	56.67%	69.73%
packages/http	94.43%	86.47%	92.62%

Unit coverage includes every backend workspace. PostgreSQL/Redis integration tests run separately.

Commit: 702257b · HTML, JSON, XML reports and job logs · attempt 1

[gitar-bot]

Code Review ✅ Approved

🟡 Medium risk · Touch-target preparation now retries within five seconds before dispatching events.

Fixes duplicate personal rows in reading leaderboards by deduplicating when a signed-in reader appears in the displayed top ten, with independent membership checks for longest streak and total reading days. Seven PostgreSQL integration regressions and 27 unit regressions passed, including ties outside displayed rows, users present in both boards, and a touch preparation retry mechanism to handle reader-test race conditions. No issues found.

Review coverage

📋 Rules No rules evaluated

🧪 Functional validation Not enabled · Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud