Repository navigation
Conversation
The Gemini API serialises Part.fileData in responses as fileData with fileUri and mimeType. parsePart matched file data only by the snake_case proto names (file_data, file_uri, mime_type), so every fileData part in a model response fell through to UnknownPart. Add the lowerCamelCase form as a second arm of the same match and keep the snake_case arm.
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 the 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 counterproductive. 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. |
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the parsePart function in content.dart to support parsing camelCase fileData (containing fileUri and mimeType) alongside the existing snake_case file_data structure. It also adds comprehensive unit tests in content_test.dart to verify correct parsing of camelCase fileData under various conditions, including with thought signatures and media resolutions. There are no review comments, and I have no additional feedback to provide.
Description
parsePartinpackages/firebase_ai/firebase_ai/lib/src/content.dartmatches every part type by its lowerCamelCase JSON key (functionCall,executableCode,codeExecutionResult,inlineData,text) except file data, which it matched only by the snake_case proto names (file_data/file_uri/mime_type). The Gemini API serialisesPart.fileDatain responses asfileData/fileUri/mimeType, so a file data part in a model response never matched and fell through toUnknownPart. Callers switching onFileDatanever saw one.This PR adds the lowerCamelCase form as a second arm of the same switch case, sharing the existing
FileData._construction sothought,thoughtSignatureandmediaResolutionare carried the same way. The snake_case arm is kept, so anything that previously parsed still does. The change is additive; no existing behaviour is modified.Tests in
test/content_test.dartcover: camelCasefileDataparses toFileDatawith the rightfileUri/mimeType; camelCase withthought: trueand athoughtSignaturekeeps both; camelCase withmediaResolutionkeeps it. The existing snake_case test is unchanged and still passes. Before the fix the three new tests fail withActual: <Instance of 'UnknownPart'>.Follow-up question for maintainers:
FileData.toJson()still emits snake_case ('file_data': {'file_uri': ..., 'mime_type': ...}). Requests work because the API accepts both spellings on input, so I left it alone here. Switching it tofileDatafor consistency with the other parts is a separate decision and I am happy to do it in another PR if wanted.Verification:
flutter testinpackages/firebase_ai/firebase_aipasses (355 tests, 9 skipped).dart analyze lib testreports no issues.flutter analyzefor the package reports 4 pre-existing errors inexample/integration_test/*from the gitignoredfirebase_options.dart, identical onmain.dart format --set-exit-if-changedon the two touched files reports 0 changed. Not run:melos bootstrapor the e2e suite.Related Issues
Fixes #18753
Checklist
///).melos run analyze) does not report any problems on my PR.Breaking Change