-
-
Notifications
You must be signed in to change notification settings - Fork 369
Fix argument null exception when updating plugin directories for erroneous plugins #3584
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: dev
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
🥷 Code experts: no user but you matched threshold 10 Jack251970 has most 👩💻 activity in the files. See details
Activity based on git-commit:
Knowledge based on git-blame: To learn more about /:\ gitStream - Visit our Docs |
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
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.
Pull Request Overview
This PR adds null-or-empty checks for plugin identifiers to prevent ArgumentNullException
when constructing plugin directory paths for plugins with missing metadata.
- Skip updating directory paths if
AssemblyName
orName
is null/empty - Prevents
Path.Combine
failures for erroneous plugins
Comments suppressed due to low confidence (2)
Flow.Launcher.Core/Plugin/PluginManager.cs:190
- Consider adding unit tests to verify that
UpdatePluginDirectory
correctly skips plugins whenAssemblyName
orName
is null or empty.
if (string.IsNullOrEmpty(metadata.AssemblyName))
Flow.Launcher.Core/Plugin/PluginManager.cs:194
- [nitpick] These two language-specific branches duplicate similar logic for combining paths. Consider extracting the identifier (
AssemblyName
orName
) and the combine logic into a helper to reduce duplication.
metadata.PluginSettingsDirectoryPath = Path.Combine(DataLocation.PluginSettingsDirectory, metadata.AssemblyName);
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
This comment has been minimized.
This comment has been minimized.
📝 WalkthroughWalkthroughValidation checks were added in the Changes
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
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.
Pull Request Overview
This PR addresses the ArgumentNullException issue when updating plugin directories by adding null or empty checks for the AssemblyName and Name properties of PluginMetadata.
- Skips updating directories for plugins with an empty AssemblyName (for .NET plugins)
- Skips updating directories for plugins with an empty Name (for non-.NET plugins)
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
Pull Request Overview
This PR prevents ArgumentNullException
in UpdatePluginDirectory
by skipping plugins whose AssemblyName
or Name
is null or empty.
- Add
string.IsNullOrEmpty
checks formetadata.AssemblyName
(for .NET plugins) andmetadata.Name
(for non-.NET plugins) - Log a warning and
continue
to skip directory updates for those erroneous plugins
Comments suppressed due to low confidence (3)
Flow.Launcher.Core/Plugin/PluginManager.cs:192
- [nitpick] The warning message logs
metadata.Name
, which may also be empty. Consider including a different identifier (e.g., plugin file path or ID) so the logged warning is more informative.
API.LogWarn(ClassName, $"AssemblyName is empty for plugin with metadata: {metadata.Name}");
Flow.Launcher.Core/Plugin/PluginManager.cs:190
- This new null-check logic should be covered by unit tests to verify that plugins with empty
AssemblyName
orName
are skipped gracefully without exceptions.
if (string.IsNullOrEmpty(metadata.AssemblyName))
Flow.Launcher.Core/Plugin/PluginManager.cs:195
- [nitpick] The directory assignment logic is duplicated in both branches. Consider extracting the common logic into a helper method or local function to reduce duplication.
metadata.PluginSettingsDirectoryPath = Path.Combine(DataLocation.PluginSettingsDirectory, metadata.AssemblyName);
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. If the flagged items are 🤯 false positivesIf items relate to a ...
|
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Flow.Launcher.Core/Plugin/PluginManager.cs (1)
200-204
: Improve log message for better debugging when Name is null/empty.The null check logic is correct and consistent with the .NET plugin validation. However, the log message could be more informative when
metadata.Name
is null or empty.Consider this improvement for clearer debugging:
- API.LogWarn(ClassName, $"Name is empty for plugin with metadata: {metadata.Name}"); + API.LogWarn(ClassName, $"Name is empty for plugin with metadata: {metadata.Name ?? "<null>"}");Or alternatively, provide more context:
- API.LogWarn(ClassName, $"Name is empty for plugin with metadata: {metadata.Name}"); + API.LogWarn(ClassName, $"Plugin Name is null or empty, skipping directory setup. Plugin directory: {metadata.PluginDirectory}");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Flow.Launcher.Core/Plugin/PluginManager.cs
(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
Flow.Launcher.Core/Plugin/PluginManager.cs (3)
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (1)
LogWarn
(270-270)Flow.Launcher/PublicAPIInstance.cs (1)
LogWarn
(271-272)Flow.Launcher.Core/Plugin/JsonRPCV2Models/JsonRPCPublicAPI.cs (1)
LogWarn
(153-156)
🪛 GitHub Actions: Check Spelling
Flow.Launcher.Core/Plugin/PluginManager.cs
[warning] 39-55: metadatas
is not a recognized word. (unrecognized-spelling)
[warning] 114-133: Reloadable
is not a recognized word. (unrecognized-spelling)
[warning] 176-193: metadatas
is not a recognized word. (unrecognized-spelling)
[warning] 178-231: metadatas
is not a recognized word. (unrecognized-spelling)
[warning] 179-238: metadatas
is not a recognized word. (unrecognized-spelling)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: build
🔇 Additional comments (1)
Flow.Launcher.Core/Plugin/PluginManager.cs (1)
190-194
: LGTM! Effective null check prevents ArgumentNullException.The validation correctly prevents the ArgumentNullException that would occur when
Path.Combine
receives null values in lines 195-196. The logging provides useful debugging information and the graceful skip behavior is appropriate for handling erroneous plugins.
If some plugins failed to construct,
Name
orAssemblyName
property will not be initialized and could be null. This can cause this issue:So we need to check it when updating plugin directories for erroneous plugins.