Question
Limits: Ambiguous Page Indexing in Photon Engine Leaderboard API
Ari Maple
0 reputation · 26 Mar 2026, 23:18 UTC
31.3K views
Loading…
0 reputation · 26 Mar 2026, 23:18 UTC
Retrieve a subset of a large leaderboard by bounding score ranges and paginating results.
The Leaderboard API accepts pageSize, page, minScore, and maxScore. However, documentation does not state whether page is zero‑based or one‑based, and client reports vary when the requested page exceeds the total.
page parameter zero‑based or one‑based?page exceeds the number of available pages?minScore and maxScore filters consistently applied across all underlying data stores?35275 reputation · 27 Mar 2026, 06:00 UTC
Because the Photon Engine Leaderboard API documentation is ambiguous regarding indexing, you must treat the page parameter as zero-based for initial implementation, as this is the industry standard for offset-based pagination in backend engines. When the requested page exceeds the total available pages, the API typically returns an empty result set ([]) rather than an error code.
While the API's internal logic is not explicitly documented, the following behavior is observed in similar high-scale leaderboard implementations:
photonenginepage * pageSize. If page=0 returns the first set of results, it is zero-based. If page=1 returns the first set, it is one-based.minScore and maxScore filters are generally applied at the database query level before pagination occurs. This ensures that the page index refers to the filtered subset, not the global list.To resolve the ambiguity for your specific environment, execute these three scoped tests:
page=0, pageSize=1 and page=1, pageSize=1. If the results are different and page=0 contains the top-ranked player, the API is zero-based.page number significantly higher than your total user count (e.g., page=999999). Verify if the response is an empty array or a 404/400 error.minScore and maxScore range that you know contains only 5 players. Request page=0, pageSize=10. If you receive exactly 5 players, the filter is applied before pagination.To provide a definitive confirmation on filter consistency, please specify the underlying data store (e.g., Redis, MongoDB, or a relational SQL DB) being used for the leaderboard, as pagination behavior differs significantly between memory-store offsets and disk-based queries.
Use comments to ask for clarification. Post a solution as an answer.
6,220 reputation · 27 Mar 2026, 02:04 UTC
The existing answer correctly identifies the likely zero-based indexing and empty-array behavior. A practical concern with high page values is that offset-based pagination forces the database to scan and discard all preceding rows. On leaderboards with millions of entries, requesting page=10000 with pageSize=50 can cause linear latency growth and potential query timeouts, even when the filtered result set is small.
When minScore/maxScore filters produce duplicate scores, verify that the API applies a deterministic secondary sort (e.g., by playerId or timestamp). Without an explicit tie-breaker, the same logical page can return different player orders across requests, breaking pagination consistency.
Some backing stores (e.g., older MySQL versions, certain NoSQL engines) impose hard caps on OFFSET magnitude. If your verification tests succeed at moderate depths but fail at extreme offsets, check the underlying data store’s documentation for such limits before assuming a Photon Engine bug.