actually detect if zero is the set recommendedInterval#729
Conversation
Summary of ChangesHello @tavdog, 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 addresses an issue where a recommendedInterval of 0 was incorrectly treated as missing metadata, causing the system to fall back to a default value of 10 minutes. The changes ensure that an explicitly configured 0 for the interval is respected. Additionally, the user interface has been improved to clearly display the recommended interval to users, providing better context for configuration. Highlights
Changelog
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.
Code Review
This pull request correctly fixes an issue where a recommendedInterval of 0 was not being respected when adding a new app, properly distinguishing between an explicitly set zero interval and the absence of metadata using the hasMetadata flag. However, it introduces a potential security risk where the update interval (uinterval) could be set to a non-positive value. If this value is later used in a scheduling context (e.g., with time.NewTicker) without further validation, it could cause the server to panic, leading to a denial-of-service. Additionally, there's an opportunity to simplify the interval calculation logic in internal/server/handlers_app.go by removing a redundant condition, which would improve code clarity and maintainability.
internal/server/handlers_app.go
Outdated
| if uinterval == 0 || (uinterval == 10 && recommendedInterval != 10) { | ||
| uinterval = recommendedInterval | ||
| } | ||
| if uinterval == 0 { | ||
| // Only fall back to 10 if no metadata was found (0 is valid when explicitly set) | ||
| if uinterval == 0 && !hasMetadata { | ||
| uinterval = 10 | ||
| } |
There was a problem hiding this comment.
The current logic for calculating uinterval allows it to be set to a non-positive value (0 or negative) if the user provides such a value or if metadata specifies it. This is a critical security concern because many scheduling systems, such as Go's time.NewTicker, will panic if provided with a non-positive interval, potentially leading to a remote denial-of-service. While the PR aims to allow 0 as a valid value, explicit validation is needed to ensure uinterval is positive before it's used in a scheduler. Additionally, the if statement on line 144 appears to be unreachable and redundant, as the preceding logic on line 140 ensures uinterval will be non-zero if !hasMetadata. Simplifying this by removing the redundant check, as suggested, would improve clarity and maintainability.
// Use recommended_interval logic. If the user didn't specify an interval,
// or used the old default of 10, use the recommended interval.
if uinterval == 0 || (uinterval == 10 && recommendedInterval != 10) {
uinterval = recommendedInterval
}
recommendedInterval = 0 was not working because 0 was considered no metadata.