-
Notifications
You must be signed in to change notification settings - Fork 125
[Storage] Improve how GetFile handles paths #1782
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: main
Are you sure you want to change the base?
Conversation
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.
Summary of Changes
Hello @a-maurice, 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 a usability and robustness issue in the Firebase Storage GetFile
method on iOS. It enhances the method's path handling capabilities, allowing it to correctly interpret and process both file://
prefixed URLs and absolute file system paths. This change simplifies API usage for developers and includes explicit error handling for invalid path conversions.
Highlights
- Improved iOS
GetFile
Path Handling: TheGetFile
method on iOS now intelligently determines if an input string is afile://
URL or an absolute file path, converting it to the appropriateNSURL
object. This allows developers to pass absolute paths directly without needing to prependfile://
. - Enhanced Error Handling: Added a check in
GetFile
to ensure the provided path can be successfully converted to a validNSURL
. If the conversion fails, the operation will now complete with ankErrorUnknown
status and a descriptive error message. - Integration Test Adaptation: A temporary modification was made to an integration test (
TestPutFileAndGetFile
) to validate the newGetFile
behavior, specifically testing its ability to handle paths without thefile://
prefix. - Release Notes Entry: An entry has been added to the
release_build_files/readme.md
under the 'Upcoming' section to document this improvement in the upcoming release notes.
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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
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 issue 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 or fill out our survey to provide feedback.
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
-
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. ↩
✅ Integration test succeeded!Requested by @a-maurice on commit 404dc99 |
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 updates the iOS implementation of GetFile
to handle absolute file paths in addition to file URIs. The core logic change is sound, but I've identified a couple of issues: an edge case with empty paths that should be handled, and some temporary test code that needs to be cleaned up before merging.
// TODO: Revert, just testing to see if this will pass without. | ||
std::string file_path = /*kFileUriScheme +*/ path; |
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.
This change appears to be for temporary testing, as indicated by the TODO
comment. This should be reverted or the test should be updated to properly validate the new functionality before this pull request is merged.
A permanent test could verify both absolute paths and file URIs to ensure both are handled correctly.
NSString* path_string = @(path); | ||
NSURL* local_file_url = nil; | ||
if ([path_string hasPrefix:@"file://"]) { | ||
// If it starts with the prefix, load it assuming a URL string. | ||
local_file_url = [NSURL URLWithString:path_string]; | ||
} else { | ||
// Otherwise, assume it is a file path. | ||
local_file_url = [NSURL fileURLWithPath:path_string]; | ||
} | ||
// If we still failed to convert the path, error out. | ||
if (local_file_url == nil) { | ||
future_impl->Complete(handle, kErrorUnknown, | ||
"Unable to convert provided path to valid URL"); | ||
return GetFileLastResult(); | ||
} |
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.
This is a good improvement to handle both absolute paths and file URIs. However, there's an edge case with an empty path string that could lead to unexpected behavior.
If path
is an empty string, [NSURL fileURLWithPath:@""]
will create a URL pointing to the current working directory. A subsequent download could then unintentionally overwrite a file in that directory. It would be safer to add a check for an empty path and return an error.
NSString* path_string = @(path);
if (path_string.length == 0) {
future_impl->Complete(handle, kErrorUnknown, "Path cannot be empty.");
return GetFileLastResult();
}
NSURL* local_file_url = nil;
if ([path_string hasPrefix:@"file://"]) {
// If it starts with the prefix, load it assuming a URL string.
local_file_url = [NSURL URLWithString:path_string];
} else {
// Otherwise, assume it is a file path.
local_file_url = [NSURL fileURLWithPath:path_string];
}
// If we still failed to convert the path, error out.
if (local_file_url == nil) {
future_impl->Complete(handle, kErrorUnknown,
"Unable to convert provided path to valid URL");
return GetFileLastResult();
}
Description
On iOS, allow absolute paths to be passed in to GetFile, instead of just file URLs.
Testing
Type of Change
Place an
x
the applicable box:Notes
Release Notes
section ofrelease_build_files/readme.md
.