-
Notifications
You must be signed in to change notification settings - Fork 0
idempotent queue #18
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
idempotent queue #18
Conversation
Summary of ChangesHello @LuisJG8, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces foundational changes aimed at enhancing the robustness and efficiency of data processing by moving towards an idempotent queue system. It includes a minor adjustment to the GitHub API rate limit handling and, more significantly, lays the groundwork for splitting large data retrieval tasks into smaller, more manageable, and idempotent units. This will help ensure that operations can be safely retried without unintended side effects and potentially improve processing speed. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
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.
Code Review
This pull request introduces a new placeholder Celery task get_more_data and adjusts the rate limit check threshold in the get_github_data function. The change in the rate limit check uses a magic number, which could lead to maintainability issues. The new task is currently empty, indicating incomplete functionality.
| remaining = remaining_api_calls[0] | ||
|
|
||
| if int(counter) == 4990: | ||
| if int(counter) == 4900: |
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.
The change from 4990 to 4900 for the rate limit check uses a magic number. It's generally better to define such thresholds as named constants to improve readability and maintainability. If the intention is to stop a certain number of calls before the actual rate_limit[1], this value should ideally be derived from rate_limit[1] to be more robust against changes in the API's total rate limit. For example, rate_limit[1] - 100 if the goal is to stop 100 calls before the limit.
| if int(counter) == 4900: | |
| if int(counter) == rate_limit[1] - 100: |
| # split the task above into small chunks to make it idempotent and faster | ||
| @app.task | ||
| def get_more_data(): | ||
| pass |
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.
The get_more_data task is currently a placeholder with just pass. While the comment indicates future plans for idempotency and speed, an empty task can be misleading or suggest incomplete work. It would be better to either implement some initial logic or, if it's not ready, consider removing it for now to avoid deploying incomplete features. If it's a planned future enhancement, a TODO comment might be more appropriate within the function body.
| # split the task above into small chunks to make it idempotent and faster | |
| @app.task | |
| def get_more_data(): | |
| pass | |
| # split the task above into small chunks to make it idempotent and faster | |
| @app.task | |
| def get_more_data(): | |
| # TODO: Implement logic to split the main task into smaller, idempotent chunks | |
| pass |
No description provided.