-
Notifications
You must be signed in to change notification settings - Fork 81
feat: add pagination support to fetch all badge templates #2895
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
feat: add pagination support to fetch all badge templates #2895
Conversation
|
Thanks for the pull request, @luisfelipec95! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
|
@luisfelipec95 Thanks for this. It looks like some of the tests are failing, can you have a look? |
| # For each iteration, fetch data using the 'next_page_url' provided by the API, | ||
| # append the results to the main list, and update the URL for the next request. | ||
| # The loop stops when there are no more pages to retrieve. | ||
| for _ in range(2, total_pages + 1): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few robustness questions:
- What's a reasonable maximum number of pages?
- What happens if you hit a rate limit or timeout?
- should you throttle the calls to not be flagged as a bot or overwhelm the backend?
- Is this ever called from a request to the credentials frontend?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback!
- I think 3 or 4 pages is a reasonable maximum.
- With the current change, any error raised during perform_request will propagate as an exception, which allows us to immediately detect issues such as rate limiting or timeouts.
- Yes, I added a minimal throttle between page requests to avoid overwhelming the Credly API and to reduce the risk of hitting rate limits.
- As far as I’ve seen, it’s only used in the Credentials admin
| # For each iteration, fetch data using the 'next_page_url' provided by the API, | ||
| # append the results to the main list, and update the URL for the next request. | ||
| # The loop stops when there are no more pages to retrieve. | ||
| for _ in range(2, total_pages + 1): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to do them all at once like this? If there's enough to paginate, do you not want to paginate our results? This could be an iterator with yield and the consumer could handle that way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback!
I see your point, but in this case I don’t think we need to introduce a generator. The number of active Credly badge templates is usually small, so pagination is unlikely to produce a large dataset. Since the consumer only needs the full list, handling everything at once keeps the implementation simpler without adding unnecessary complexity.
| response = self.perform_request("get", next_page_url) | ||
| results.extend(response.get("data", [])) | ||
|
|
||
| next_page_url = response.get("metadata", {}).get("next_page_url") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no try block, so you want to raise exception if any one call fails (eg. for rate limiting reasons)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback!
I added the retry loop, so transient failures are handled, and if all attempts fail, the exception is still raised.
Sure, the failing tests were due to a mismatch between the expected return structure and the actual output. I updated the test accordingly, and the failures should now be resolved. |
Description
This PR enhances the synchronization process of badge templates from the Credly API by implementing pagination support.
Previously, the fetch_badge_templates function only retrieved the first page of results (up to 50 templates).
Now, the function iterates through all available pages to fetch every active badge template, ensuring no data is missed during synchronization.
Supporting information
Testing instructions