We ran into some timeout issues on gladiator related to hitting the new /api/v2/contests endpoint. I believe the issue is due to the heavy payload we are trying to return to the client. For example, we defaulted to 20 contests per page, each contest could have a 5+ competitions, each competition could have 1k+ contestants in it. Another thing we were doing were returning overall users in the competition plus an array of subscribers (similar in size to contestants) plus an array of unsubscribers (smaller in size).
This PR does two things
Limit the results to 1 contest per page, be default, the client can still ask for more, but the request will probably timeout.
Remove the subscribers property, which means the client would have to do it's own logic to determine who is subscribed based on the full set of users in competitions and the set of unsubscribed users/
How should this be manually tested?
hit GET /api/v2/contests and make sure you only get one per page.
What's this PR do?
We ran into some timeout issues on gladiator related to hitting the new
/api/v2/contestsendpoint. I believe the issue is due to the heavy payload we are trying to return to the client. For example, we defaulted to 20 contests per page, each contest could have a 5+ competitions, each competition could have 1k+ contestants in it. Another thing we were doing were returning overall users in the competition plus an array of subscribers (similar in size to contestants) plus an array of unsubscribers (smaller in size).This PR does two things
subscribersproperty, which means the client would have to do it's own logic to determine who is subscribed based on the full set of users in competitions and the set of unsubscribed users/How should this be manually tested?
hit
GET /api/v2/contestsand make sure you only get one per page.Any background context you want to provide?
See above
What are the relevant tickets?
Fixes 🐛