feat: Flutter SDK update for version 20.2.0 #276
Conversation
WalkthroughThe release updates version to 20.2.0 across pubspec and client headers. It introduces transactions for Databases and TablesDB, adding Transaction and TransactionList models. New Databases and TablesDB service methods include list/create/get/update/deleteTransaction and createOperations. Existing CRUD methods for documents/rows gain an optional transactionId parameter and propagate it in requests. Documentation examples are added/updated for all new endpoints and parameters. README dependency is updated to ^20.2.0. CHANGELOG includes a 20.2.0 entry. Unit tests are added for transaction models and new service methods in both Databases and TablesDB. Suggested reviewers
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: 6
🧹 Nitpick comments (6)
docs/examples/tablesdb/create-operations.md (1)
12-21: Replace hard tabs with spaces for consistency.The markdownlint tool has flagged hard tabs in the operations list. Replace them with spaces to maintain consistency with Markdown formatting standards.
Apply this diff to replace hard tabs with spaces:
operations: [ - { - "action": "create", - "databaseId": "<DATABASE_ID>", - "tableId": "<TABLE_ID>", - "rowId": "<ROW_ID>", - "data": { - "name": "Walter O'Brien" - } - } + { + "action": "create", + "databaseId": "<DATABASE_ID>", + "tableId": "<TABLE_ID>", + "rowId": "<ROW_ID>", + "data": { + "name": "Walter O'Brien" + } + } ], // optionallib/src/models/transaction_list.dart (1)
13-20: Consider adding null safety checks infromMap.The
fromMapfactory directly accesses map keys without validation, which could throw at runtime if the API returns null values or missing keys. While this may align with existing patterns in the codebase, consider adding defensive checks for robustness.Apply this diff to add null safety:
factory TransactionList.fromMap(Map<String, dynamic> map) { return TransactionList( - total: map['total'], + total: map['total'] ?? 0, transactions: List<Transaction>.from( - map['transactions'].map((p) => Transaction.fromMap(p)), + (map['transactions'] as List<dynamic>? ?? []).map((p) => Transaction.fromMap(p)), ), ); }Alternatively, verify that the API contract guarantees these fields will always be present and document this assumption.
lib/services/databases.dart (2)
119-139: Strengthen type safety for operations parameter.The
operationsparameter is typed asList<Map>?, which provides minimal type safety. Consider usingList<Map<String, dynamic>>?to make the expected structure more explicit.Future<models.Transaction> createOperations({ required String transactionId, - List<Map>? operations, + List<Map<String, dynamic>>? operations, }) async {
98-117: Reconsider content-type header on DELETE request.The
deleteTransactionmethod sets'content-type': 'application/json'but has an emptyapiParamsmap. DELETE requests typically don't require a content-type header when there's no body. This is likely harmless but may be unnecessary.Future deleteTransaction({required String transactionId}) async { final String apiPath = '/databases/transactions/{transactionId}'.replaceAll( '{transactionId}', transactionId, ); final Map<String, dynamic> apiParams = {}; - final Map<String, String> apiHeaders = {'content-type': 'application/json'}; + final Map<String, String> apiHeaders = {}; final res = await client.call( HttpMethod.delete, path: apiPath, params: apiParams, headers: apiHeaders, ); return res.data; }lib/services/tables_db.dart (2)
117-137: Strengthen type safety for operations parameter.The
operationsparameter usesList<Map>?, which is too loose. UseList<Map<String, dynamic>>?for better type safety, consistent with the suggestion inDatabases.createOperations.Future<models.Transaction> createOperations({ required String transactionId, - List<Map>? operations, + List<Map<String, dynamic>>? operations, }) async {
96-115: Reconsider content-type header on DELETE request.Similar to
Databases.deleteTransaction: the content-type header is set on a DELETE request with no body. This is likely unnecessary.Future deleteTransaction({required String transactionId}) async { final String apiPath = '/tablesdb/transactions/{transactionId}'.replaceAll( '{transactionId}', transactionId, ); final Map<String, dynamic> apiParams = {}; - final Map<String, String> apiHeaders = {'content-type': 'application/json'}; + final Map<String, String> apiHeaders = {}; final res = await client.call( HttpMethod.delete, path: apiPath, params: apiParams, headers: apiHeaders, ); return res.data; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (42)
CHANGELOG.md(1 hunks)README.md(1 hunks)docs/examples/databases/create-document.md(1 hunks)docs/examples/databases/create-operations.md(1 hunks)docs/examples/databases/create-transaction.md(1 hunks)docs/examples/databases/decrement-document-attribute.md(1 hunks)docs/examples/databases/delete-document.md(1 hunks)docs/examples/databases/delete-transaction.md(1 hunks)docs/examples/databases/get-document.md(1 hunks)docs/examples/databases/get-transaction.md(1 hunks)docs/examples/databases/increment-document-attribute.md(1 hunks)docs/examples/databases/list-documents.md(1 hunks)docs/examples/databases/list-transactions.md(1 hunks)docs/examples/databases/update-document.md(1 hunks)docs/examples/databases/update-transaction.md(1 hunks)docs/examples/databases/upsert-document.md(1 hunks)docs/examples/tablesdb/create-operations.md(1 hunks)docs/examples/tablesdb/create-row.md(1 hunks)docs/examples/tablesdb/create-transaction.md(1 hunks)docs/examples/tablesdb/decrement-row-column.md(1 hunks)docs/examples/tablesdb/delete-row.md(1 hunks)docs/examples/tablesdb/delete-transaction.md(1 hunks)docs/examples/tablesdb/get-row.md(1 hunks)docs/examples/tablesdb/get-transaction.md(1 hunks)docs/examples/tablesdb/increment-row-column.md(1 hunks)docs/examples/tablesdb/list-rows.md(1 hunks)docs/examples/tablesdb/list-transactions.md(1 hunks)docs/examples/tablesdb/update-row.md(1 hunks)docs/examples/tablesdb/update-transaction.md(1 hunks)docs/examples/tablesdb/upsert-row.md(1 hunks)lib/models.dart(2 hunks)lib/services/databases.dart(14 hunks)lib/services/tables_db.dart(13 hunks)lib/src/client_browser.dart(1 hunks)lib/src/client_io.dart(1 hunks)lib/src/models/transaction.dart(1 hunks)lib/src/models/transaction_list.dart(1 hunks)pubspec.yaml(1 hunks)test/services/databases_test.dart(1 hunks)test/services/tables_db_test.dart(1 hunks)test/src/models/transaction_list_test.dart(1 hunks)test/src/models/transaction_test.dart(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
docs/examples/tablesdb/create-operations.md
12-12: Hard tabs
Column: 1
(MD010, no-hard-tabs)
13-13: Hard tabs
Column: 1
(MD010, no-hard-tabs)
14-14: Hard tabs
Column: 1
(MD010, no-hard-tabs)
15-15: Hard tabs
Column: 1
(MD010, no-hard-tabs)
16-16: Hard tabs
Column: 1
(MD010, no-hard-tabs)
17-17: Hard tabs
Column: 1
(MD010, no-hard-tabs)
18-18: Hard tabs
Column: 1
(MD010, no-hard-tabs)
19-19: Hard tabs
Column: 1
(MD010, no-hard-tabs)
20-20: Hard tabs
Column: 1
(MD010, no-hard-tabs)
21-21: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/examples/databases/create-operations.md
15-15: Bare URL used
(MD034, no-bare-urls)
docs/examples/tablesdb/create-row.md
21-21: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (30)
CHANGELOG.md (1)
3-6: LGTM!The changelog entry accurately reflects the new transaction support feature introduced in version 20.2.0.
pubspec.yaml (1)
2-2: LGTM!Version correctly bumped to 20.2.0, consistent with the release notes and other files.
docs/examples/databases/create-document.md (1)
21-21: LGTM!The documentation properly demonstrates the new optional
transactionIdparameter, maintaining consistency with the existing parameter documentation pattern.README.md (1)
24-24: LGTM!The dependency version is correctly updated to match the new package version.
lib/src/client_browser.dart (1)
43-43: LGTM!The SDK version header is correctly updated to 20.2.0, consistent with the package version and the parallel change in
lib/src/client_io.dart.docs/examples/tablesdb/update-transaction.md (1)
1-13: LGTM!The documentation properly demonstrates the new
updateTransactionmethod with clear parameter examples and appropriate optional markers.lib/src/client_io.dart (1)
61-61: LGTM!The SDK version header is correctly updated to 20.2.0, consistent with the package version and the parallel change in
lib/src/client_browser.dart.docs/examples/tablesdb/upsert-row.md (1)
15-15: LGTM!The documentation properly demonstrates the new optional
transactionIdparameter, maintaining consistency with other TablesDB examples.docs/examples/databases/list-documents.md (1)
13-13: LGTM!The addition of the optional
transactionIdparameter correctly documents the new transaction support feature. The syntax and usage are appropriate.docs/examples/databases/get-document.md (1)
14-14: LGTM!The documentation correctly demonstrates the optional
transactionIdparameter usage ingetDocument.lib/src/models/transaction.dart (2)
1-30: LGTM!The model class structure, field declarations, constructor, and documentation are well-implemented.
43-52: LGTM!The
toMapmethod correctly serializes all fields.docs/examples/tablesdb/list-transactions.md (1)
1-11: LGTM!The example correctly demonstrates the new
listTransactionsAPI with appropriate syntax and return type.docs/examples/tablesdb/increment-row-column.md (1)
16-16: LGTM!The documentation correctly demonstrates the optional
transactionIdparameter usage inincrementRowColumn.docs/examples/tablesdb/list-rows.md (1)
13-13: LGTM!The documentation correctly demonstrates the optional
transactionIdparameter usage inlistRows.docs/examples/tablesdb/update-row.md (1)
15-15: LGTM!The documentation correctly demonstrates the optional
transactionIdparameter usage inupdateRow.docs/examples/tablesdb/decrement-row-column.md (1)
1-17: LGTM!The documentation example correctly demonstrates the usage of
decrementRowColumnwith the new optionaltransactionIdparameter. The syntax is correct, and the parameter is appropriately marked as optional.docs/examples/databases/create-transaction.md (1)
1-11: LGTM!The documentation example correctly demonstrates the usage of
createTransactionwith the optionalttlparameter. The syntax is correct and aligns with the new Transaction API.docs/examples/tablesdb/get-row.md (1)
1-15: LGTM!The documentation example correctly demonstrates the usage of
getRowwith the new optionaltransactionIdparameter. The syntax is correct and consistent with other transaction-related examples.docs/examples/databases/update-document.md (1)
1-16: LGTM!The documentation example correctly demonstrates the usage of
updateDocumentwith the new optionaltransactionIdparameter. The syntax is correct and consistent with the broader transaction API additions.docs/examples/tablesdb/delete-transaction.md (1)
1-11: LGTM!The documentation example correctly demonstrates the usage of
deleteTransactionwith the requiredtransactionIdparameter. The syntax is correct and aligns with the new TablesDB transaction API.docs/examples/databases/delete-transaction.md (1)
1-11: LGTM!The documentation example correctly demonstrates the usage of
deleteTransactionwith the requiredtransactionIdparameter. The syntax is correct and aligns with the new Databases transaction API.lib/models.dart (1)
22-22: LGTM!The new transaction model exports are correctly placed:
transaction_list.dartis grouped with other list models, andtransaction.dartis grouped with individual models, maintaining the existing file organization pattern.Also applies to: 55-55
docs/examples/databases/delete-document.md (1)
13-13: LGTM!The documentation correctly demonstrates the new optional
transactionIdparameter fordeleteDocument.docs/examples/databases/update-transaction.md (1)
1-13: LGTM!The documentation clearly demonstrates the
updateTransactionmethod with all parameters properly annotated. The example correctly shows thatcommitandrollbackare optional parameters.test/services/tables_db_test.dart (1)
58-173: LGTM!The transaction-related tests are well-structured and consistent with the existing test patterns. Each test properly:
- Sets up mock data matching the expected response structure
- Configures the mock client to return that data
- Invokes the method under test
- Asserts the correct return type
The
deleteTransactiontest appropriately omits response assertions since it performs a deletion operation.docs/examples/databases/upsert-document.md (1)
15-15: LGTM!The documentation correctly demonstrates the new optional
transactionIdparameter forupsertDocument.test/services/databases_test.dart (1)
58-173: LGTM!The transaction-related tests are comprehensive and follow the established testing patterns. Each test properly:
- Mocks the expected response data with appropriate structure
- Configures the HTTP method (GET, POST, PATCH, DELETE)
- Invokes the corresponding Databases method
- Validates the return type (TransactionList or Transaction)
The
deleteTransactiontest correctly omits response validation since it's a void operation.lib/services/databases.dart (1)
146-428: LGTM: transactionId parameter propagation.All deprecated document methods consistently propagate the optional
transactionIdparameter through their API calls. The implementation maintains backward compatibility while enabling transactional operations.lib/services/tables_db.dart (1)
141-400: LGTM: transactionId parameter propagation.All row methods consistently propagate the optional
transactionIdparameter through their API calls, mirroring the pattern inDatabases. The implementation enables transactional operations across TablesDB.
| "isAdmin": false | ||
| }, | ||
| permissions: ["read("any")"], // optional | ||
| transactionId: '<TRANSACTION_ID>', // optional |
There was a problem hiding this comment.
Fix hard tab character.
The static analysis tool flagged a hard tab character on this line. For consistency with the rest of the codebase, use spaces for indentation.
Replace the hard tab with spaces to match the indentation of surrounding lines.
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
21-21: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/examples/tablesdb/create-row.md around line 21, the line contains a hard
tab character for indentation ("transactionId: '<TRANSACTION_ID>', //
optional"); replace the hard tab with spaces to match surrounding lines'
indentation (use the project's standard number of spaces, e.g., 2 or 4) so the
file uses spaces consistently and the static analysis warning is resolved.
| /// Update a transaction, to either commit or roll back its operations. | ||
| Future<models.Transaction> updateTransaction({ | ||
| required String transactionId, | ||
| bool? commit, | ||
| bool? rollback, | ||
| }) async { | ||
| final String apiPath = '/databases/transactions/{transactionId}'.replaceAll( | ||
| '{transactionId}', | ||
| transactionId, | ||
| ); | ||
|
|
||
| final Map<String, dynamic> apiParams = { | ||
| 'commit': commit, | ||
| 'rollback': rollback, | ||
| }; | ||
|
|
||
| final Map<String, String> apiHeaders = {'content-type': 'application/json'}; | ||
|
|
||
| final res = await client.call( | ||
| HttpMethod.patch, | ||
| path: apiPath, | ||
| params: apiParams, | ||
| headers: apiHeaders, | ||
| ); | ||
|
|
||
| return models.Transaction.fromMap(res.data); | ||
| } |
There was a problem hiding this comment.
Clarify commit/rollback mutual exclusivity.
The method accepts both commit and rollback boolean parameters simultaneously. If a caller passes both as true (or both as false), the behavior is ambiguous. Consider validating that only one action is specified, or document the precedence if the backend handles this.
Example validation:
Future<models.Transaction> updateTransaction({
required String transactionId,
bool? commit,
bool? rollback,
}) async {
+ if (commit == true && rollback == true) {
+ throw ArgumentError('Cannot specify both commit and rollback');
+ }
+
final String apiPath = '/databases/transactions/{transactionId}'.replaceAll(
'{transactionId}',
transactionId,
);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /// Update a transaction, to either commit or roll back its operations. | |
| Future<models.Transaction> updateTransaction({ | |
| required String transactionId, | |
| bool? commit, | |
| bool? rollback, | |
| }) async { | |
| final String apiPath = '/databases/transactions/{transactionId}'.replaceAll( | |
| '{transactionId}', | |
| transactionId, | |
| ); | |
| final Map<String, dynamic> apiParams = { | |
| 'commit': commit, | |
| 'rollback': rollback, | |
| }; | |
| final Map<String, String> apiHeaders = {'content-type': 'application/json'}; | |
| final res = await client.call( | |
| HttpMethod.patch, | |
| path: apiPath, | |
| params: apiParams, | |
| headers: apiHeaders, | |
| ); | |
| return models.Transaction.fromMap(res.data); | |
| } | |
| /// Update a transaction, to either commit or roll back its operations. | |
| Future<models.Transaction> updateTransaction({ | |
| required String transactionId, | |
| bool? commit, | |
| bool? rollback, | |
| }) async { | |
| if (commit == true && rollback == true) { | |
| throw ArgumentError('Cannot specify both commit and rollback'); | |
| } | |
| final String apiPath = '/databases/transactions/{transactionId}'.replaceAll( | |
| '{transactionId}', | |
| transactionId, | |
| ); | |
| final Map<String, dynamic> apiParams = { | |
| 'commit': commit, | |
| 'rollback': rollback, | |
| }; | |
| final Map<String, String> apiHeaders = {'content-type': 'application/json'}; | |
| final res = await client.call( | |
| HttpMethod.patch, | |
| path: apiPath, | |
| params: apiParams, | |
| headers: apiHeaders, | |
| ); | |
| return models.Transaction.fromMap(res.data); | |
| } |
🤖 Prompt for AI Agents
In lib/services/databases.dart around lines 70 to 96, the updateTransaction
method currently allows commit and rollback to be passed together or both
omitted, creating ambiguous behavior; add validation at the top of the method to
ensure exactly one action is specified (i.e., commit XOR rollback) and throw an
ArgumentError (or similar) if both or neither are provided, then only include
the chosen boolean in apiParams before calling client.call so the request
unambiguously indicates the intended action.
| /// Update a transaction, to either commit or roll back its operations. | ||
| Future<models.Transaction> updateTransaction({ | ||
| required String transactionId, | ||
| bool? commit, | ||
| bool? rollback, | ||
| }) async { | ||
| final String apiPath = '/tablesdb/transactions/{transactionId}'.replaceAll( | ||
| '{transactionId}', | ||
| transactionId, | ||
| ); | ||
|
|
||
| final Map<String, dynamic> apiParams = { | ||
| 'commit': commit, | ||
| 'rollback': rollback, | ||
| }; | ||
|
|
||
| final Map<String, String> apiHeaders = {'content-type': 'application/json'}; | ||
|
|
||
| final res = await client.call( | ||
| HttpMethod.patch, | ||
| path: apiPath, | ||
| params: apiParams, | ||
| headers: apiHeaders, | ||
| ); | ||
|
|
||
| return models.Transaction.fromMap(res.data); | ||
| } |
There was a problem hiding this comment.
Clarify commit/rollback mutual exclusivity.
Same as in Databases.updateTransaction: accepting both commit and rollback boolean parameters simultaneously creates ambiguity when both are true or both are false. Validate mutual exclusivity or document the precedence.
Future<models.Transaction> updateTransaction({
required String transactionId,
bool? commit,
bool? rollback,
}) async {
+ if (commit == true && rollback == true) {
+ throw ArgumentError('Cannot specify both commit and rollback');
+ }
+
final String apiPath = '/tablesdb/transactions/{transactionId}'.replaceAll(
'{transactionId}',
transactionId,
);🤖 Prompt for AI Agents
In lib/services/tables_db.dart around lines 68 to 94, the updateTransaction
method accepts nullable commit and rollback flags but does not enforce mutual
exclusivity, which allows ambiguous calls (both true/false/null); validate
inputs at the top of the method so exactly one of commit or rollback is true
(reject when both are true, both false, or both null) and throw an ArgumentError
with a clear message if the check fails, and when building apiParams only
include the chosen non-null flag so the request payload is unambiguous.
| factory Transaction.fromMap(Map<String, dynamic> map) { | ||
| return Transaction( | ||
| $id: map['\$id'].toString(), | ||
| $createdAt: map['\$createdAt'].toString(), | ||
| $updatedAt: map['\$updatedAt'].toString(), | ||
| status: map['status'].toString(), | ||
| operations: map['operations'], | ||
| expiresAt: map['expiresAt'].toString(), | ||
| ); | ||
| } |
There was a problem hiding this comment.
Ensure type safety for the operations field.
Line 38 directly assigns map['operations'] without type casting, while other fields use .toString() for safe conversion. If the API returns operations as a String or another type, this could cause a runtime error.
Apply this diff to add type safety:
factory Transaction.fromMap(Map<String, dynamic> map) {
return Transaction(
$id: map['\$id'].toString(),
$createdAt: map['\$createdAt'].toString(),
$updatedAt: map['\$updatedAt'].toString(),
status: map['status'].toString(),
- operations: map['operations'],
+ operations: map['operations'] as int,
expiresAt: map['expiresAt'].toString(),
);
}Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In lib/src/models/transaction.dart around lines 32 to 41, the factory assigns
operations directly from map['operations'] which is not type-safe; update the
factory to normalize operations by checking its runtime type: if it's already a
List, cast it to List<Map<String, dynamic>> (or List<dynamic> and map each item
to Map<String, dynamic>), if it's a JSON String decode it with jsonDecode and
validate it produces a List, and if null provide an empty list or a sensible
default; throw or handle unexpected types explicitly so the
Transaction.operations field always has a well-typed value.
| expect(result.total, 5); | ||
| expect(result.transactions, []); |
There was a problem hiding this comment.
Fix inconsistent indentation.
Lines 15-16 have excessive leading whitespace compared to the surrounding code. While this doesn't affect functionality, it reduces code readability.
Apply this diff to fix the indentation:
- expect(result.total, 5);
- expect(result.transactions, []);
+ expect(result.total, 5);
+ expect(result.transactions, []);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| expect(result.total, 5); | |
| expect(result.transactions, []); | |
| expect(result.total, 5); | |
| expect(result.transactions, []); |
🤖 Prompt for AI Agents
In test/src/models/transaction_list_test.dart around lines 15 to 16, the two
expect lines have excessive leading whitespace; remove the extra indentation so
those lines match the surrounding code's indentation level (align with the other
statements in the test block) to improve readability.
| expect(result.$id, '259125845563242502'); | ||
| expect(result.$createdAt, '2020-10-15T06:38:00.000+00:00'); | ||
| expect(result.$updatedAt, '2020-10-15T06:38:00.000+00:00'); | ||
| expect(result.status, 'pending'); | ||
| expect(result.operations, 5); | ||
| expect(result.expiresAt, '2020-10-15T06:38:00.000+00:00'); |
There was a problem hiding this comment.
Fix inconsistent indentation.
Lines 19-24 have excessive leading whitespace compared to the surrounding code. While this doesn't affect functionality, it reduces code readability.
Apply this diff to fix the indentation:
- expect(result.$id, '259125845563242502');
- expect(result.$createdAt, '2020-10-15T06:38:00.000+00:00');
- expect(result.$updatedAt, '2020-10-15T06:38:00.000+00:00');
- expect(result.status, 'pending');
- expect(result.operations, 5);
- expect(result.expiresAt, '2020-10-15T06:38:00.000+00:00');
+ expect(result.$id, '259125845563242502');
+ expect(result.$createdAt, '2020-10-15T06:38:00.000+00:00');
+ expect(result.$updatedAt, '2020-10-15T06:38:00.000+00:00');
+ expect(result.status, 'pending');
+ expect(result.operations, 5);
+ expect(result.expiresAt, '2020-10-15T06:38:00.000+00:00');📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| expect(result.$id, '259125845563242502'); | |
| expect(result.$createdAt, '2020-10-15T06:38:00.000+00:00'); | |
| expect(result.$updatedAt, '2020-10-15T06:38:00.000+00:00'); | |
| expect(result.status, 'pending'); | |
| expect(result.operations, 5); | |
| expect(result.expiresAt, '2020-10-15T06:38:00.000+00:00'); | |
| expect(result.$id, '259125845563242502'); | |
| expect(result.$createdAt, '2020-10-15T06:38:00.000+00:00'); | |
| expect(result.$updatedAt, '2020-10-15T06:38:00.000+00:00'); | |
| expect(result.status, 'pending'); | |
| expect(result.operations, 5); | |
| expect(result.expiresAt, '2020-10-15T06:38:00.000+00:00'); |
🤖 Prompt for AI Agents
In test/src/models/transaction_test.dart around lines 19 to 24, the expect
statements have excessive leading whitespace causing inconsistent indentation;
normalize the indentation to match the surrounding code style by removing the
extra leading spaces so the expect lines align with adjacent test code (use the
same indentation level as the other statements in the test block).
2 participants
This PR contains updates to the Flutter SDK for version 20.2.0.
Summary by CodeRabbit