feat: add polling system to dynamic reloading

[Yuan325]

Support polling system to existing Toolbox dynamic reloading feature.

flag	description	default
--poll-interval	Specifies the polling frequency (seconds) for configuration file updates.	0

With --poll-interval = 0, it will not run the polling system at all.

When polling is active, Toolbox checks for configuration file updates at every specified interval (in seconds).

Fixes #2346

[gemini-code-assist]

Summary of Changes

Hello @Yuan325, I'm Gemini Code Assist¹! 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 enhances the dynamic reloading feature by integrating a polling system. This allows the application to detect changes in configuration files by periodically checking their modification times, which is particularly useful in environments where file system events (like inotify) are not reliably propagated, such as NFS mounts. The new functionality is controlled via a configurable interval, providing flexibility for users to enable or disable it as needed.

Highlights

• New Polling System: Introduced a new polling mechanism for dynamic configuration reloading, allowing the system to periodically check for file updates.
• Configuration Option: Added a new command-line flag, --poll-interval, to specify the frequency (in seconds) for configuration file polling. A value of 0 disables polling.
• NFS Compatibility: Provided documentation and a tip for optimizing polling effectiveness in Kubernetes environments, specifically regarding actimeo settings for PersistentVolumes or StorageClasses.

Changelog

• cmd/root.go
  • Added a new command-line flag --poll-interval to configure the polling frequency.
  • Introduced a checkModTime helper function to compare file modification times.
  • Modified the watchChanges function to accept a pollTickerSecond parameter.
  • Implemented the core polling logic within watchChanges, using a ticker to periodically scan for file changes based on modification times.
  • Updated the call to watchChanges to pass the configured PollInterval.
• cmd/root_test.go
  • Updated the watchChanges function call in TestSingleEdit to include the new pollTickerSecond parameter, setting it to 0.
• docs/en/reference/cli.md
  • Documented the new --poll-interval flag in the CLI reference table.
  • Added a new section explaining the --polling-interval flag and a tip for Kubernetes users regarding actimeo settings.
• internal/server/config.go
  • Added a PollInterval field to the ServerConfig struct to store the polling frequency.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[gemini-code-assist]

Code Review

This pull request introduces a polling system for dynamic configuration reloading, which is useful in environments where filesystem notifications are unreliable. A new --poll-interval flag controls this feature. The implementation is mostly correct, but I've identified a few areas for improvement:

• The polling mechanism doesn't detect file deletions, which can lead to stale configurations.
• The loops for checking file changes can be made more efficient by exiting early once a change is found.
• There's a minor issue with a logger call.
• The documentation has a couple of small errors (a typo and an incorrect flag name).

Overall, this is a valuable addition. Addressing these points will make the feature more robust and efficient.

I am having trouble creating individual review comments. Click here to see my feedback.

cmd/root.go (868-898)

The current polling implementation does not detect when a configuration file is deleted. It only checks for modifications on existing files or new files. This can lead to stale configurations if a tool file is removed, as the server will not reload to remove the tool.

To fix this, the polling logic should be enhanced to detect deletions:

• When watching a folder, you can compare the list of files currently in the directory with the keys in the lastSeen map to identify any deleted files.
• When watching specific files, you should check the error returned by os.Stat in checkModTime. If os.IsNotExist(err) is true for a file that was previously in lastSeen, it indicates the file has been deleted.

cmd/root.go (874)

The logger call here seems to be using fmt.Sprintf-style formatting (%s), but the underlying slog logger expects key-value pairs for structured logging. This will result in an incorrect log message. The error should be passed as a value to a key, like "error".

logger.WarnContext(ctx, "error reading tools folder", "folder", folderToWatch, "error", err)

cmd/root.go (877-884)

For efficiency, you can break out of the loop once a file change is detected. There's no need to continue checking other files in the directory.

for _, f := range files {
					if !f.IsDir() && (strings.HasSuffix(f.Name(), ".yaml") || strings.HasSuffix(f.Name(), ".yml")) {
						fullPath := filepath.Join(folderToWatch, f.Name())
						if checkModTime(fullPath, lastSeen) {
							changed = true
							break
						}
					}
				}

cmd/root.go (888-892)

Similar to the folder watching logic, you can break out of this loop for efficiency once a file change is detected.

for _, f := range files {
					if checkModTime(f, lastSeen) {
						changed = true
						break
					}
				}

docs/en/reference/cli.md (140)

There's a small inconsistency here. The flag is --poll-interval, but the documentation refers to it as --polling-interval.

Use the `--poll-interval` flag to manually detect configuration file updates.

docs/en/reference/cli.md (144)

There's a typo here.

For polling to be effective when running Kubernetes, PersistentVolume or

[Yuan325]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a polling system for dynamic configuration reloading, which is particularly useful in environments like Kubernetes with NFS where filesystem events may not be reliably propagated. A new --poll-interval flag controls this feature. The implementation is sound, adding a ticker and polling logic to check for file modifications and deletions. I've identified a couple of areas for improvement: one to prevent an unnecessary configuration reload on the first poll, and another to optimize by removing a redundant system call. Overall, this is a valuable addition for improving the robustness of the dynamic reload feature.

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[Yuan325]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a polling system for dynamic configuration reloading, which is a valuable addition for environments where filesystem events are unreliable. The implementation is solid, adding a new --poll-interval flag and the corresponding logic to watch for file changes at a specified frequency. My review includes a few suggestions to improve code quality, such as enhancing logging practices, increasing efficiency in file stat operations, and refactoring duplicated code for better maintainability. I also found a minor typo in the documentation.

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[Yuan325]

/gemini review

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[github-actions]

🔎 Preview at https://googleapis.github.io/genai-toolbox/previews/PR-2466/

[github-actions]

🧨 Preview deployments removed.