You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The miner detail page renders its "add to watchlist" star button as soon as a githubId is present in the URL, without first checking that the miner actually exists.
This means a user who lands on the miner detail page with any arbitrary value in the githubId query parameter - for example, by typing one in directly, by following a stale link to a deleted account, or by a redirect that loses its target - sees an active star button on top of the page's own "No data found" error block. Clicking the star pins the unknown id into the watchlist exactly as if it were a real miner.
Once an unknown id has been pinned, the watchlist behaves inconsistently:
The watchlist sidebar badge and the per-category counts include the unknown entry in their totals.
The watchlist's miners table only shows entries that resolve against the live list of tracked miners, so the unknown id is silently filtered out of the visible list.
The result is a watchlist where the badge says something like "Watchlist 2" while the visible list shows fewer items, and there is no in-app affordance to clear the missing entry. The user has to manually remove the value from localStorage to fix it.
The repository, PR, and bounty/issue detail pages already gate their watchlist buttons behind a successful data fetch - only the miner detail page is missing this guard.
Expected behavior:
The star button on the miner detail page should not be available until the underlying miner has been confirmed to exist. While the data is still loading, or when the fetch resolves with no record, the star should be hidden (or disabled) so the user can't pin something the rest of the app considers nonexistent.
The watchlist itself should remain internally consistent: any watched entry that can't be resolved against the live data should be visible to the user with a way to remove it, so the counts in the sidebar always match what the user can actually see and act on.
Repro:
Open /miners/details?githubId=123456789 (or any other value not present on the leaderboard).
Observe that the page renders the "No data found for GitHub user…" error block, but the star button at the top of the page is still active.
Click the star, then navigate to /watchlist.
Observe that the sidebar shows a watchlist count that includes the unknown entry, while the miners tab shows no row for it and offers no way to clean it up.
The miner detail page renders its "add to watchlist" star button as soon as a
githubIdis present in the URL, without first checking that the miner actually exists.This means a user who lands on the miner detail page with any arbitrary value in the
githubIdquery parameter - for example, by typing one in directly, by following a stale link to a deleted account, or by a redirect that loses its target - sees an active star button on top of the page's own "No data found" error block. Clicking the star pins the unknown id into the watchlist exactly as if it were a real miner.Once an unknown id has been pinned, the watchlist behaves inconsistently:
The result is a watchlist where the badge says something like "Watchlist 2" while the visible list shows fewer items, and there is no in-app affordance to clear the missing entry. The user has to manually remove the value from
localStorageto fix it.The repository, PR, and bounty/issue detail pages already gate their watchlist buttons behind a successful data fetch - only the miner detail page is missing this guard.
Expected behavior:
Repro:
/miners/details?githubId=123456789(or any other value not present on the leaderboard)./watchlist.82.mp4