feat: Flutter SDK update for version 20.3.2 #287
Conversation
WalkthroughThis pull request performs a patch version bump from 20.3.1 to 20.3.2 across configuration, documentation, and client files. It updates version references in CHANGELOG.md, pubspec.yaml, README.md, and SDK version headers in client_browser.dart and client_io.dart. The flutter_web_auth_2 dependency is upgraded from ^4.1.0 to ^5.0.0-alpha.3. Type annotations in documentation examples are corrected from UInt8List to Uint8List across multiple avatar and storage service examples. Additionally, several service files (databases.dart, functions.dart, storage.dart, tables_db.dart) remove conditional null checks for specific API parameters (permissions, transactionId, scheduledAt, name), changing the request payload structure to always include these fields with their values, including null when applicable. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Areas requiring extra attention:
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (20)
CHANGELOG.md(1 hunks)README.md(1 hunks)docs/examples/avatars/get-browser.md(1 hunks)docs/examples/avatars/get-credit-card.md(1 hunks)docs/examples/avatars/get-favicon.md(1 hunks)docs/examples/avatars/get-flag.md(1 hunks)docs/examples/avatars/get-image.md(1 hunks)docs/examples/avatars/get-initials.md(1 hunks)docs/examples/avatars/get-qr.md(1 hunks)docs/examples/avatars/get-screenshot.md(4 hunks)docs/examples/storage/get-file-download.md(1 hunks)docs/examples/storage/get-file-preview.md(1 hunks)docs/examples/storage/get-file-view.md(1 hunks)lib/services/databases.dart(6 hunks)lib/services/functions.dart(1 hunks)lib/services/storage.dart(1 hunks)lib/services/tables_db.dart(6 hunks)lib/src/client_browser.dart(1 hunks)lib/src/client_io.dart(1 hunks)pubspec.yaml(2 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
docs/examples/avatars/get-screenshot.md
11-11: Bare URL used
(MD034, no-bare-urls)
🔇 Additional comments (28)
CHANGELOG.md (1)
3-6: Version entry is properly formatted and positioned. The CHANGELOG addition correctly documents the OAuth2 infinite redirect fix for v20.3.2.docs/examples/avatars/get-initials.md (1)
10-10: Correct type annotation for byte data. Updated fromUInt8List(incorrect) toUint8List(correct Dart typed data class).README.md (1)
24-24: Version documentation updated consistently. SDK dependency version bumped to match pubspec.yaml.lib/src/client_io.dart (1)
61-61: SDK version header updated consistently. Reflects the 20.3.2 patch version.pubspec.yaml (2)
2-2: Version bump to 20.3.2 is consistent across all files. Patch version update aligns with CHANGELOG and client headers.
23-23: I'll continue verification by checking whether a stable v5.0.0 release is available and examining the codebase for context around this version choice.Let me search for changelog details between alpha versions:
Based on my verification using web searches, here's my assessment:
Key findings:
The latest stable release is 4.1.0, with 5.0.0-alpha.7 as the latest prerelease. The PR uses
^5.0.0-alpha.3, which is outdated.The only breaking change in v5.0.0-alpha.3 is iOS/macOS native code migration to Swift Package Manager (SPM), which affects native integration setup but not the Dart API.
The API signature for
FlutterWebAuth2.authenticate()remains stable across alpha versions based on documented migration guides—the function acceptsurl,callbackUrlScheme, and optionalFlutterWebAuth2Options.Recommendation:
If the app targets iOS/macOS, verify that iOS Deployment Target is 17.4+ and macOS is 14.4+ to support v5.0.0. Consider updating to
^5.0.0-alpha.7for the latest fixes, or wait for a stable v5.0.0 release. If you're not targeting iOS/macOS, the SPM change has no impact.Verify the following in your codebase:
- Does the app target iOS/macOS platforms?
- Are the iOS Deployment Target and macOS minimum versions compatible with v5.0.0 requirements?
- Whether using
alpha.3specifically is intentional or if newer alpha should be used.lib/src/client_browser.dart (1)
43-43: SDK version header updated consistently. Reflects the 20.3.2 patch version.docs/examples/avatars/get-image.md (1)
10-10: Correct type annotation updated. Changed fromUInt8ListtoUint8List(correct Dart type).docs/examples/avatars/get-favicon.md (1)
10-10: Correct type annotation updated. Changed fromUInt8ListtoUint8List(correct Dart type).docs/examples/storage/get-file-download.md (1)
10-10: LGTM! Typo corrected.The type annotation has been correctly updated from
UInt8ListtoUint8List, which is the proper Dart type.docs/examples/storage/get-file-preview.md (1)
10-10: LGTM! Type annotation corrected.Correctly updated from
UInt8ListtoUint8List.docs/examples/avatars/get-flag.md (1)
10-10: LGTM! Type annotation corrected.Correctly updated from
UInt8ListtoUint8List.docs/examples/storage/get-file-view.md (1)
10-10: LGTM! Type annotation corrected.Correctly updated from
UInt8ListtoUint8List.docs/examples/avatars/get-screenshot.md (2)
10-10: LGTM! Type annotation corrected.Correctly updated from
UInt8ListtoUint8List.
16-30: LGTM! Enum usage improved and new parameters documented.The enum values are now properly prefixed (
Theme.light,Timezone.africaAbidjan,Output.jpg) for better type safety and clarity. The new optional parameters (touch,permissions,sleep,width,height,quality) expand the API documentation appropriately.lib/services/tables_db.dart (6)
157-162: Verify backend compatibility with null parameter values.In
createRow, thepermissionsandtransactionIdparameters are now always included in the API payload, even when null. Previously, these were conditionally included. Ensure the backend endpoint/tablesdb/{databaseId}/tables/{tableId}/rowscorrectly handles explicitnullvalues versus omitted fields.
218-222: Verify backend compatibility with null parameter values.In
upsertRow, thepermissionsandtransactionIdparameters are now always included in the API payload, even when null. Ensure the backend endpoint handles this change appropriately.
249-253: Verify backend compatibility with null parameter values.In
updateRow, thepermissionsandtransactionIdparameters are now always included in the API payload, even when null. Ensure the backend endpoint handles this change appropriately.
277-279: Verify backend compatibility with null transactionId value.In
deleteRow, thetransactionIdparameter is now always included in the API payload, even when null. Ensure the backend endpoint handles this change appropriately.
307-311: Verify backend compatibility with null parameter values.In
decrementRowColumn, theminandtransactionIdparameters are now always included in the API payload, even when null. Ensure the backend endpoint handles this change appropriately.
339-343: Verify backend compatibility with null parameter values.In
incrementRowColumn, themaxandtransactionIdparameters are now always included in the API payload, even when null. Ensure the backend endpoint handles this change appropriately.lib/services/functions.dart (1)
44-51: Verify backend compatibility with null scheduledAt values.The
scheduledAtparameter is now always included in the API request payload, even when its value is null, whereas all other optional parameters are conditionally included only when non-null. The model documentation confirms the backend handles empty/null values ("If left empty, execution will be queued immediately"), but verify that the backend API endpoint/functions/{functionId}/executionscorrectly handles receiving an explicitnullvalue forscheduledAtversus the field being omitted entirely. Note: A recent fix in version 20.3.1 addressed null value handling; confirm this change aligns with that fix.lib/services/databases.dart (3)
265-266: Consistent payload behavior change for transactionId and permissions.Similar to other methods in this file,
transactionIdandpermissionsare now always included in the payload. Thedataparameter correctly remains conditionally included since it's genuinely optional for PATCH operations.Verify that the backend API endpoints for these deprecated methods still accept these parameters as explicit nulls, as this is a payload structure change.
Also applies to: 294-294
327-328: Verify min/max boundary parameter handling with null values.The
min,max, andtransactionIdparameters are now always included in the payload. WhiletransactionIdfollows the same pattern as other methods, the boundary parameters (minandmax) now send explicit null instead of omitting the constraint. Verify that the backend interprets explicit null as "no boundary" rather than treating it as an error or unexpected value.Also applies to: 361-362
168-169: Verify backend compatibility with null values in API payload.The
permissionsandtransactionIdparameters are nullable (List<String>?andString?respectively) but are now unconditionally included in the API request payload at lines 168–169 and 232–233, even when null. Previously, these keys were omitted when null. Ensure the backend API correctly handles explicit null values for these fields, as this differs from the conditional pattern used elsewhere in the codebase (e.g.,databases.dartlines 135, 200).Also applies to: 232-233
docs/examples/avatars/get-qr.md (1)
10-10: LGTM! Correct Dart type annotation.The type has been corrected from
UInt8ListtoUint8List, which is the proper Dart type name.docs/examples/avatars/get-browser.md (1)
10-10: LGTM! Correct Dart type annotation.The type has been corrected from
UInt8ListtoUint8List.docs/examples/avatars/get-credit-card.md (1)
10-10: LGTM! Correct Dart type annotation.The type has been corrected from
UInt8ListtoUint8List.
| final Map<String, dynamic> apiParams = { | ||
| if (name != null) 'name': name, | ||
| if (permissions != null) 'permissions': permissions, | ||
| 'name': name, | ||
| 'permissions': permissions, | ||
| }; |
There was a problem hiding this comment.
🧩 Analysis chain
Verify backend compatibility with null parameter values.
The name and permissions parameters are now always included in the API request payload, even when their values are null. Previously, these fields were conditionally included only when non-null. Ensure that the backend API endpoint /storage/buckets/{bucketId}/files/{fileId} correctly handles receiving explicit null values for these fields versus the fields being omitted entirely.
🏁 Script executed:
#!/bin/bash
# Description: Check if similar unconditional inclusion patterns exist in other service files to understand the scope of this API contract change.
# Search for updateFile-like methods and their parameter handling
rg -n -B5 -A10 "Future<models\.File> update" lib/services/storage.dart lib/services/databases.dart --type dartLength of output: 1022
I need to examine the complete updateFile method and verify the actual change. Let me gather more information:
---
🏁 Script executed:
```shell
#!/bin/bash
# View the complete updateFile method to see how apiParams are used
sed -n '104,140p' lib/services/storage.dart
Length of output: 1176
🏁 Script executed:
#!/bin/bash
# Check for similar patterns in other service files (databases, users, etc.)
fd -e dart -path "lib/services/*.dart" -type f -exec basename {} \; | sortLength of output: 168
🏁 Script executed:
#!/bin/bash
# Search for conditional parameter inclusion patterns in the codebase
rg -n "if.*\?" lib/services/storage.dart -A2 -B2 | head -40Length of output: 0
Let me check the git history and look for conditional parameter patterns across the codebase:
---
🏁 Script executed:
```shell
#!/bin/bash
# Check git diff to see what changed in this method
git diff HEAD -- lib/services/storage.dart | grep -A30 -B5 "updateFile"
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Search for conditional parameter inclusion patterns across all service files
find lib/services -name "*.dart" -type f | xargs grep -n "if.*!= null" | head -20Length of output: 1519
🏁 Script executed:
#!/bin/bash
# Look for similar update methods and their parameter handling patterns
find lib/services -name "*.dart" -type f | xargs grep -n "Future.*update" -A15 | grep -E "(Future|if|apiParams|permissions)" | head -40Length of output: 3313
Let me verify if this pattern violation is specific to updateFile or if storage.dart generally lacks conditional patterns:
---
🏁 Script executed:
```shell
#!/bin/bash
# Check if other methods in storage.dart use conditional inclusion patterns
grep -n "if.*!= null" lib/services/storage.dart
Length of output: 951
🏁 Script executed:
#!/bin/bash
# View other update/create methods in storage.dart to see their parameter handling
grep -n "apiParams = {" lib/services/storage.dart -A10 | head -50Length of output: 1495
Use conditional inclusion for nullable parameters to match the established pattern in this file.
The updateFile method unconditionally includes name and permissions in the API request, even when null. This violates the established pattern used throughout storage.dart—other methods like listBuckets() (lines 19-21), createFile() (line 62), and getFilePreview() (lines 191-202) all conditionally include nullable parameters only when non-null.
Update lines 113-115 to:
final Map<String, dynamic> apiParams = {
if (name != null) 'name': name,
if (permissions != null) 'permissions': permissions,
};This ensures consistency with the codebase pattern and prevents sending explicit null values to the backend, which may be handled differently than omitted fields.
🤖 Prompt for AI Agents
In lib/services/storage.dart around lines 113 to 116, the apiParams map for
updateFile unconditionally includes name and permissions (which may be null);
change it to use conditional map entries so nullable fields are only added when
non-null (i.e., include 'name' only if name != null and 'permissions' only if
permissions != null) to match the established pattern and avoid sending explicit
nulls to the backend.
This PR contains updates to the Flutter SDK for version 20.3.2.
Summary by CodeRabbit
Bug Fixes
Documentation