Dependabot added for automated dependency updates #671
Conversation
|
🎉 Welcome @Charan-BS!
We appreciate your contribution! 🚀 |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughThis PR performs a major Appwrite database API migration from document-based Databases to table-based TablesDB across controllers and services, adds message deletion functionality with UI and localization, introduces Punjabi language support, creates GitHub issue templates for structured workflows, updates theme colors, configures Dependabot, adds test coverage for new APIs, and publishes a multi-language changelog. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Areas requiring extra attention:
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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: 16
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/controllers/upcomming_rooms_controller.dart (1)
125-150: Potential crash when no subscriber document found.If the query returns no rows (e.g., due to a race condition or data inconsistency), calling
.rows.firston Line 138 will throw aStateError. Consider adding a check for empty results:- var subscribeDocument = await tablesDB - .listRows( - databaseId: upcomingRoomsDatabaseId, - tableId: subscribedUserTableId, - queries: [ - Query.and([ - Query.equal('userID', authStateController.uid), - Query.equal('upcomingRoomId', upcomingRoomId), - ]), - ], - ) - .then((value) => value.rows.first); + final result = await tablesDB.listRows( + databaseId: upcomingRoomsDatabaseId, + tableId: subscribedUserTableId, + queries: [ + Query.and([ + Query.equal('userID', authStateController.uid), + Query.equal('upcomingRoomId', upcomingRoomId), + ]), + ], + ); + if (result.rows.isEmpty) { + log('No subscription found for room $upcomingRoomId'); + return; + } + final subscribeDocument = result.rows.first;
🧹 Nitpick comments (9)
lib/l10n/app_hi.arb (1)
1761-1772: Inconsistent formatting and missing description metadata.The new localization entries have inconsistent structure:
deleteMessageTitleanddeleteMessageContenthave@description blocksthisMessageWasDeletedandfailedToDeleteMessageare missing their@description blocks- Extra blank lines (1771-1772) before the closing brace
Apply this diff to add missing descriptions and fix formatting:
"thisMessageWasDeleted": "यह संदेश हटा दिया गया है", -"failedToDeleteMessage": "संदेश हटाने में विफल रहा" - - +"@thisMessageWasDeleted": { + "description": "Text shown in place of a deleted message." +}, +"failedToDeleteMessage": "संदेश हटाने में विफल रहा", +"@failedToDeleteMessage": { + "description": "Error message shown when a message deletion fails." +} }lib/l10n/app_localizations_kn.dart (1)
1353-1365: Consider translating placeholder English strings to Kannada.Lines 1361 and 1364 return English strings in the Kannada localization file. While this may be intentional for consistency during development, consider providing proper Kannada translations for a complete localized experience.
lib/l10n/app_localizations_gu.dart (1)
1346-1358: Consider translating placeholder English strings to Gujarati.Lines 1354 and 1357 return English strings in the Gujarati localization file. The first two strings are properly translated to Gujarati, but the last two remain in English. For consistency and a complete localized experience, consider providing Gujarati translations for all four strings.
lib/l10n/app_en.arb (1)
1761-1770: Consider adding description blocks for consistency.Lines 1769-1770 (
thisMessageWasDeletedandfailedToDeleteMessage) are missing@description blocks. For consistency with the ARB format used throughout this file, consider adding description metadata for these keys as well.lib/l10n/app_localizations.dart (1)
13-13: LGTM! Punjabi localization and message deletion strings added correctly.The Punjabi language support is properly integrated across
supportedLocales,isSupported, andlookupAppLocalizations. The four new message deletion getters align with the chat message deletion feature.Minor documentation gap: Lines 2483 and 2489 show "No description provided" for
thisMessageWasDeletedandfailedToDeleteMessage. Consider adding descriptions for consistency with other localization entries.Also applies to: 106-106, 2470-2493, 2506-2513, 2532-2533
test/controllers/user_profile_controller_test.dart (1)
287-289: Method name references outdated terminology.The test calls
convertAppwriteDocListToStoryListbut now operates onRowobjects. Consider renaming the production method toconvertAppwriteRowListToStoryListfor consistency with the TablesDB migration.lib/views/screens/room_chat_screen.dart (2)
390-405: Hardcoded colors may break dark theme accessibility.The reply preview uses hardcoded
Colors.blueandColors.blackwhich may cause contrast issues in dark theme. Consider using theme-aware colors for consistency with the rest of the styling updates.Text( "@${widget.message.replyTo!.creatorUsername}", - style: const TextStyle( + style: TextStyle( fontWeight: FontWeight.bold, - color: Colors.blue, + color: Theme.of(context).colorScheme.primary, ), ), Text( widget.message.replyTo!.content, maxLines: 1, style: TextStyle( - color: Colors.black, + color: Theme.of(context).colorScheme.onSecondaryContainer, ), overflow: TextOverflow.ellipsis, ),
554-565: Reply preview in input field also uses hardcoded colors.Similar to the message item, this reply preview uses hardcoded
Colors.blue. Consider updating to use theme-aware colors for consistency.Text( "@${chatController.replyingTo.value?.creatorUsername ?? ""}", - style: const TextStyle( + style: TextStyle( fontWeight: FontWeight.bold, - color: Colors.blue, + color: Theme.of(context).colorScheme.primary, ), ),lib/controllers/upcomming_rooms_controller.dart (1)
365-394: Subscriber cleanup could benefit from batch/parallel deletion.The
deleteAllDeletedUpcomingRoomsSubscribersmethod deletes subscribers sequentially. For rooms with many subscribers, this could be slow. Consider parallel deletion usingFuture.wait:Future<void> deleteAllDeletedUpcomingRoomsSubscribers( String upcomingRoomId, ) async { List<Row> deletedUpcomingRoomSubscribers = await tablesDB .listRows( databaseId: upcomingRoomsDatabaseId, tableId: subscribedUserTableId, queries: [ Query.equal('upcomingRoomId', [upcomingRoomId]), ], ) .then((value) => value.rows); - for (Row subscriber in deletedUpcomingRoomSubscribers) { - await tablesDB.deleteRow( - databaseId: upcomingRoomsDatabaseId, - tableId: subscribedUserTableId, - rowId: subscriber.$id, - ); - } + await Future.wait( + deletedUpcomingRoomSubscribers.map( + (subscriber) => tablesDB.deleteRow( + databaseId: upcomingRoomsDatabaseId, + tableId: subscribedUserTableId, + rowId: subscriber.$id, + ), + ), + ); }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (72)
.github/ISSUE_TEMPLATE/ci_cd_tooling.yml(1 hunks).github/ISSUE_TEMPLATE/dependency_update.yml(1 hunks).github/ISSUE_TEMPLATE/new_release.yml(1 hunks).github/ISSUE_TEMPLATE/testing.yml(1 hunks).github/ISSUE_TEMPLATE/translation.yml(1 hunks).github/ISSUE_TEMPLATE/ui_ux_update.yml(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks).github/depandabot.yml(1 hunks)CHANGELOG.md(1 hunks)ios/Runner/Info.plist(1 hunks)lib/controllers/auth_state_controller.dart(5 hunks)lib/controllers/change_email_controller.dart(2 hunks)lib/controllers/delete_account_controller.dart(4 hunks)lib/controllers/edit_profile_controller.dart(7 hunks)lib/controllers/email_verify_controller.dart(3 hunks)lib/controllers/explore_story_controller.dart(25 hunks)lib/controllers/friend_calling_controller.dart(6 hunks)lib/controllers/friends_controller.dart(6 hunks)lib/controllers/live_chapter_controller.dart(5 hunks)lib/controllers/onboarding_controller.dart(5 hunks)lib/controllers/pair_chat_controller.dart(11 hunks)lib/controllers/room_chat_controller.dart(8 hunks)lib/controllers/rooms_controller.dart(5 hunks)lib/controllers/single_room_controller.dart(9 hunks)lib/controllers/upcomming_rooms_controller.dart(8 hunks)lib/controllers/user_profile_controller.dart(8 hunks)lib/l10n/app_en.arb(1 hunks)lib/l10n/app_hi.arb(1 hunks)lib/l10n/app_localizations.dart(5 hunks)lib/l10n/app_localizations_en.dart(1 hunks)lib/l10n/app_localizations_gu.dart(1 hunks)lib/l10n/app_localizations_hi.dart(1 hunks)lib/l10n/app_localizations_kn.dart(1 hunks)lib/l10n/app_localizations_mr.dart(1 hunks)lib/l10n/app_localizations_pa.dart(1 hunks)lib/l10n/app_pa.arb(1 hunks)lib/models/message.dart(7 hunks)lib/services/appwrite_service.dart(2 hunks)lib/services/room_service.dart(4 hunks)lib/themes/theme.dart(2 hunks)lib/themes/theme_icon_enum.dart(1 hunks)lib/utils/constants.dart(4 hunks)lib/utils/enums/update_enums.dart(1 hunks)lib/views/screens/add_chapter_screen.dart(1 hunks)lib/views/screens/chapter_play_screen.dart(1 hunks)lib/views/screens/edit_profile_screen.dart(1 hunks)lib/views/screens/email_verification_screen.dart(1 hunks)lib/views/screens/live_chapter_screen.dart(0 hunks)lib/views/screens/room_chat_screen.dart(14 hunks)lib/views/widgets/rating_sheet.dart(2 hunks)lib/views/widgets/report_widget.dart(1 hunks)project_structure.txt(4 hunks)test/controllers/auth_state_controller_test.dart(8 hunks)test/controllers/auth_state_controller_test.mocks.dart(45 hunks)test/controllers/change_email_controller_test.dart(5 hunks)test/controllers/change_email_controller_test.mocks.dart(3 hunks)test/controllers/edit_profile_controller_test.dart(1 hunks)test/controllers/edit_profile_controller_test.mocks.dart(3 hunks)test/controllers/explore_story_controller_test.dart(6 hunks)test/controllers/explore_story_controller_test.mocks.dart(3 hunks)test/controllers/friend_calling_controller_test.dart(7 hunks)test/controllers/friend_calling_controller_test.mocks.dart(3 hunks)test/controllers/friends_controller_test.dart(9 hunks)test/controllers/room_chat_controller_test.dart(1 hunks)test/controllers/room_chat_controller_test.mocks.dart(1 hunks)test/controllers/rooms_controller_test.dart(1 hunks)test/controllers/rooms_controller_test.mocks.dart(1 hunks)test/controllers/upcoming_controller_tests.dart(1 hunks)test/controllers/upcoming_controller_tests.mocks.dart(1 hunks)test/controllers/user_profile_controller_test.dart(9 hunks)test/controllers/user_profile_controller_test.mocks.dart(3 hunks)untranslated.txt(3 hunks)
💤 Files with no reviewable changes (1)
- lib/views/screens/live_chapter_screen.dart
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: M4dhav
Repo: AOSSIE-Org/Resonate PR: 510
File: .github/workflows/build_and_deploy.yml:31-36
Timestamp: 2025-08-31T16:18:53.594Z
Learning: For the AOSSIE-Org/Resonate project, build system requirements like Java version setup are considered separate from dependency update PRs and should be handled in dedicated PRs focused on build system improvements.
🪛 LanguageTool
CHANGELOG.md
[style] ~247-~247: Using many exclamation marks might seem excessive (in this case: 15 exclamation marks for a text that’s 4507 characters long)
Context: ... ಆರಂಭ ಉತ್ತಮ ಅನುಭವಕ್ಕಾಗಿ ಈಗಲೇ ನವೀಕರಿಸಿ! 🎉
(EN_EXCESSIVE_EXCLAMATION)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Run Software Tests
🔇 Additional comments (97)
lib/views/screens/add_chapter_screen.dart (2)
177-177: Discrepancy between PR objectives and actual PR scope.The PR objectives state this PR adds Dependabot configuration (Fixes #586), yet the AI-generated summary describes a comprehensive migration from Appwrite Databases/Document API to TablesDB/Row API, message deletion functionality, localization updates, theme color changes, and extensive test updates. Meanwhile, this file exhibits only a trailing newline change with no functional modifications.
This inconsistency suggests either the PR objectives are incomplete or the AI summary conflates multiple PRs. Please clarify the actual scope of this PR.
1-176: Code structure and logic look sound; no functional changes detected.The
AddNewChapterScreencorrectly manages chapter state, integrates localization, and delegates story operations toExploreStoryController. UI layout is well-structured with proper separation of current and newly added chapters. Navigation and state management are appropriate for the feature.lib/themes/theme_icon_enum.dart (2)
1-14: LGTM on code structure and quality.The enum is well-structured with proper constant initialization, valid Flutter Material Design icons, and clear intent. No functional or structural issues detected.
15-15: PR scope mismatch — clarify relationship between Dependabot configuration and codebase migration.The PR objectives state this PR adds Dependabot configuration, but the AI-generated summary and actual file contents reflect a substantial codebase migration (Appwrite Databases→TablesDB/Rows, localization expansion to Punjabi, theme updates, GitHub templates, etc.). This file represents one of many theme-related changes, which are orthogonal to Dependabot setup.
Please clarify:
- Is this PR intended to be a single, comprehensive refactor covering dependency automation + API migration + localization + theme updates, or
- Should these concerns be split into separate, focused PRs (e.g., one for Dependabot, one for API migration, one for localization)?
Based on the learnings from prior reviews, build/dependency tooling updates are typically handled separately from feature/migration work.
lib/views/screens/chapter_play_screen.dart (1)
254-254: Formatting improvement approved.Adding the end-of-file newline is a best practice that aligns with POSIX standards and common code style guidelines. No functional changes introduced.
lib/views/screens/edit_profile_screen.dart (1)
361-361: LGTM!Trailing newline addition is a standard formatting fix that aligns with common code style conventions.
lib/views/screens/email_verification_screen.dart (1)
265-265: LGTM!Trailing newline formatting fix consistent with the other files in this PR.
lib/utils/enums/update_enums.dart (1)
6-6: LGTM!Trailing newline formatting fix. The enum definition is well-structured.
.github/PULL_REQUEST_TEMPLATE.md (1)
16-21: LGTM!These additions provide more granular categorization for PRs, which is especially useful for:
- Automated Dependabot PRs (via "Dependency update")
- Localization contributions (via "Translation")
- CI/CD and tooling changes like the Dependabot configuration itself
The descriptions in parentheses provide helpful guidance for contributors.
ios/Runner/Info.plist (1)
14-14: Punjabi localization properly integrated.The addition of
pa(Punjabi) toCFBundleLocalizationsis correct. All corresponding Flutter localization files are in place:app_pa.arb,app_localizations_pa.dart, and thesupportedLocaleslist includesLocale('pa').lib/models/message.dart (1)
11-11: LGTM! Clean implementation of the soft-delete pattern.The
isDeletedfield is correctly integrated across the entire Message model with proper default handling (falseinfromJson) to maintain backward compatibility with existing data.Also applies to: 29-29, 46-46, 64-64, 81-81, 95-95, 111-111
untranslated.txt (1)
1-79: Documentation file tracks expected translation gaps.This file correctly documents the untranslated keys for the message deletion feature across multiple locales. This is expected during incremental localization work.
CHANGELOG.md (1)
1-249: LGTM! Well-structured multi-language changelog.The changelog is comprehensive and properly organized with version sections and language-specific blocks. The static analysis hint about exclamation marks is a false positive—enthusiastic tone is appropriate for user-facing release notes.
.github/ISSUE_TEMPLATE/new_release.yml (1)
1-59: LGTM! Well-structured release preparation template.The template provides clear guidance with appropriate required fields, helpful placeholders, and a comprehensive release checklist. This will standardize the release process effectively.
.github/ISSUE_TEMPLATE/dependency_update.yml (1)
1-83: LGTM! Comprehensive dependency update template.The template effectively captures all necessary information for dependency updates, with well-chosen required fields and a comprehensive dropdown for update reasons. This complements the Dependabot configuration nicely.
.github/ISSUE_TEMPLATE/ci_cd_tooling.yml (1)
1-76: LGTM! Well-designed CI/CD improvement template.The template provides appropriate structure for CI/CD proposals with clear categorization and impact assessment. This aligns well with the project's practice of handling build system improvements separately from dependency updates.
Based on learnings, this separation of concerns (CI/CD tooling vs. dependency updates) matches the project's established workflow patterns.
.github/ISSUE_TEMPLATE/testing.yml (1)
1-66: LGTM! Well-structured testing issue template.The template provides clear guidance for proposing test improvements with appropriate required fields and helpful placeholders.
.github/ISSUE_TEMPLATE/ui_ux_update.yml (1)
1-63: LGTM! Comprehensive UI/UX issue template.The template includes excellent guidance, such as mentioning WCAG AA standards for accessibility, which encourages best practices.
project_structure.txt (1)
5-16: LGTM! Project structure updates reflect the additions correctly.The structure properly documents the new issue templates, localization files, and test files added in this PR.
Also applies to: 27-27, 283-285, 453-458, 463-463
lib/l10n/app_localizations_hi.dart (1)
1349-1362: LGTM! Hindi translations for message deletion added correctly.The new translation strings for delete message functionality are properly integrated with appropriate Hindi translations.
.github/ISSUE_TEMPLATE/translation.yml (1)
1-59: LGTM! Helpful translation issue template.This template aligns well with the localization expansion evident in this PR (Punjabi support, delete message strings). It will help contributors properly document translation work.
lib/themes/theme.dart (1)
21-24: LGTM! Theme color additions are consistent across light and dark modes.The new color properties (
surfaceContainerHighest,onSurfaceVariant,secondaryContainer) are properly defined for both themes with appropriate color values for each mode.Also applies to: 100-103
lib/controllers/email_verify_controller.dart (2)
116-120: Parameter names correctly align with TablesDB API.The Appwrite TablesDB API uses
databaseId,tableId, androwIdparameters for the getRow() method. All 14 usages across the codebase consistently use these parameter names, including the code in lines 116-120 of email_verify_controller.dart. The migration from the legacy naming convention has been completed uniformly throughout the application.
23-23: No action required. TablesDB is the correct and recommended API for Appwrite 20.3.1.TablesDB is recommended for new projects, and all new features land in the TablesDB API. The implementation in email_verify_controller.dart is correct and aligned with Appwrite's current best practices.
lib/l10n/app_localizations_en.dart (1)
1345-1358: LGTM!The new localization getters for message deletion are properly structured, following the existing pattern with correct
@overrideannotations and clear English text.lib/l10n/app_pa.arb (1)
585-600: LGTM - Message deletion strings properly localized.The Punjabi translations for the message deletion feature (
deleteMessageTitle,deleteMessageContent,thisMessageWasDeleted,failedToDeleteMessage) are properly structured with appropriate@description blocks.lib/views/widgets/report_widget.dart (1)
52-57: Migration fromcreateDocumenttocreateRowis correctly implemented.The code properly uses the TablesDB API with the required parameters:
databaseId,tableId,rowId, anddata. This matches the official Appwrite TablesDB signature for creating rows.lib/services/appwrite_service.dart (1)
28-34: Remove orphaned comment on line 29.The migration from
DatabasestoTablesDBis correct. However, line 29 contains an orphaned comment (// Instantiates a new Databases Instance if it doesn't exist) that should be removed as it references the old API.lib/controllers/delete_account_controller.dart (1)
15-15: LGTM! TablesDB migration is consistent.The migration from Appwrite's Databases API to TablesDB API is correctly implemented throughout this controller. All method calls, parameter names, and field types have been properly updated to use the new API surface.
Also applies to: 28-28, 44-59
lib/controllers/friends_controller.dart (1)
13-13: LGTM! Complete TablesDB migration with realtime channel update.The migration is thorough and includes:
- Field and constructor parameter updates
- All CRUD operations migrated to row-based equivalents
- Realtime channel path correctly updated to use
tables.$tableId.rowssyntaxThe changes maintain existing functionality while adopting the new TablesDB API.
Also applies to: 24-24, 29-29, 72-78, 82-91, 98-112, 123-134, 137-145, 148-148
lib/services/room_service.dart (1)
37-87: LGTM! Comprehensive room service migration to TablesDB.All data access operations have been successfully migrated:
- Query operations updated to use
listRowswith proper table/row identifiers- CRUD operations correctly use row-based methods
- Participant counting logic properly adjusted to use
rows.lengthThe migration maintains all existing functionality while adopting the TablesDB API.
Also applies to: 180-194, 222-268
lib/controllers/pair_chat_controller.dart (1)
35-35: LGTM! Pair chat controller successfully migrated to TablesDB.The migration includes:
- Field and method call updates throughout the controller
- Realtime channel paths updated to use
tables.$tableId.rowssyntax- Result iteration properly switched from
documentstorows- All CRUD operations correctly use row-based equivalents
The controller maintains its functionality while adopting the new API.
Also applies to: 59-65, 87-94, 100-106, 112-113, 132-146, 164-177, 182-183, 210-234, 242-250, 266-275
test/controllers/rooms_controller_test.dart (1)
29-157: Excellent test coverage for search functionality.The test suite comprehensively covers:
- Basic name and description filtering
- Case-insensitive matching
- Empty query handling
- Edge cases (no matches, special characters)
- Partial string matching
- Multi-field search
- Search state management (clearing, flags)
This provides strong confidence in the search feature's correctness.
lib/controllers/rooms_controller.dart (1)
5-5: LGTM! Clean migration from Databases to TablesDB API.The migration is consistently applied throughout:
- Import directive correctly hides Flutter's
Rowto avoid naming conflicts- Field updated from
DatabasestoTablesDB- All methods properly migrated:
listDocuments→listRows,getDocument→getRow- Identifiers correctly updated:
collectionId→tableId,documentId→rowId- Data access patterns preserved with
Rowobjects and.rowsiterationAlso applies to: 25-25, 38-103
lib/controllers/change_email_controller.dart (1)
22-34: LGTM! Consistent TablesDB migration.Constructor and field declarations properly updated to use
TablesDB. All database operations correctly migrated to the table/row API (listRows,updateRow) with appropriate identifier updates (tableId,rowId).Also applies to: 38-70
lib/controllers/edit_profile_controller.dart (1)
26-53: LGTM! Comprehensive TablesDB migration.All database operations properly migrated:
- Constructor and field declarations updated to
TablesDB- Username availability check uses
getRowwithtableId/rowId- Profile save operations correctly use
createRow,updateRow, anddeleteRow- All identifier updates applied consistently
Also applies to: 161-319
lib/controllers/single_room_controller.dart (1)
5-5: LGTM! Complete TablesDB migration with realtime support.Migration correctly implemented across:
- Import directive hides Flutter's
Row- Field updated to
TablesDB- Participant data operations use
Rowobjects and table/row API- Realtime channel path properly updated from
databases.$id.collections.$id.documentstodatabases.$id.tables.$id.rows- All participant management operations (add, update, remove, kick, report) use new API
Also applies to: 45-45, 67-152, 239-355
test/controllers/upcoming_controller_tests.dart (1)
19-25: LGTM! Comprehensive test coverage for UpcomingRoomsController.Well-structured test suite with:
- Proper mocks for TablesDB and dependencies aligned with the API migration
- Remove room functionality: 6 test cases covering removal, persistence, duplicates, multiple removals, non-existent rooms, and cross-instance persistence
- Search functionality: 8 test cases covering filtering by name/description, case sensitivity, empty queries, no matches, partial matches, clearing search, and multi-field matching
- Proper setup/teardown with GetStorage and GetX test mode
- Good edge case coverage
Also applies to: 78-322
test/controllers/explore_story_controller_test.dart (1)
18-18: LGTM! Test mocks properly migrated to TablesDB.Test setup correctly updated:
@GenerateMocksannotation changed toTablesDB- Mock data migrated from
DocumenttoRowwith$tableIdfields- Controller initialization uses
MockTablesDBandtablesparameter- All mock expectations use
listRows,RowList, andtableIdinstead of old APIAlso applies to: 25-124, 175-232
lib/controllers/live_chapter_controller.dart (6)
22-40: LGTM! TablesDB migration looks correct.The field type, constructor parameter, and initializer are correctly updated from
Databases/databasestoTablesDB/tables, with proper fallback toAppwriteService.getTables().
42-45: Channel path correctly updated for TablesDB.The realtime subscription channel path is correctly updated from
databases...collections...documentstodatabases...tables...rows, matching the new TablesDB API structure.
97-108: Row-based create operations look correct.Both
createRowcalls correctly usetableIdandrowIdparameters instead of the previouscollectionId/documentId. The data payloads remain unchanged.
162-167: Update operation correctly migrated toupdateRow.
228-233: Leave room update operation correctly migrated.
245-254: Delete operations correctly migrated todeleteRow.Both delete calls for the live chapter and attendees rows correctly use the new
deleteRowAPI withtableId/rowIdparameters.lib/controllers/explore_story_controller.dart (8)
8-8: Good use ofhide Rowto avoid naming conflict.Hiding
Rowfrom the Flutter import correctly prevents collision with Appwrite'sRowmodel type used throughout this file.
21-56: TablesDB field and constructor migration looks correct.The field, constructor parameter, and initializer are properly updated to use
TablesDBwith thegetTables()fallback.
88-95:getRowcall correctly usestableIdandrowId.
138-156:listRowsusage is correct.The query returns a
RowListand accesses.rowsto get the list ofRowobjects. The rest of the search logic remains unchanged.
192-207: Helper method signature correctly updated toList<Row>.
456-476: User liked stories fetch correctly migrated.The chained
listRowsandgetRowcalls correctly use the new API, and theList<Row>type annotations are consistent.
511-527: Delete all story likes correctly iterates overRowobjects.
743-744: Converter method signature correctly acceptsList<Row>.lib/controllers/friend_calling_controller.dart (4)
22-37: TablesDB migration looks correct for FriendCallingController.Field, constructor parameter, and initializer properly updated to use
TablesDB/tables.
64-69:createRowcall for starting a call is correct.
123-150: Answer call flow correctly usesgetRowandupdateRow.The call document retrieval and status update correctly use the new row-based API with
tableId/rowId.
195-198: Channel path correctly updated.The realtime subscription channel correctly uses
databases...tables...rowspattern.lib/controllers/room_chat_controller.dart (5)
26-26: TablesDB field initialization is correct.
77-103: Message loading correctly migrated tolistRows/getRow.The iteration over
messagesList.rowsand retrieval of reply data usinggetRowwithtableId/rowIdis correct. The 404 handling for missing replyTo documents is preserved.
106-165:sendMessagecorrectly usescreateRowand setsisDeleted: false.New messages properly initialize
isDeleted: false, and the row creation uses the correcttableId/rowIdparameters.
167-205:editMessagecorrectly preservesisDeleted: falseduring edits.Setting
isDeleted: falseon edit ensures an edited message is not marked as deleted. TheupdateRowcall is correctly migrated.
221-291: Realtime subscription correctly migrated and handlesisDeleted.The channel path uses the new
tables...rowsformat. The update handler correctly propagatesisDeletedfrom the payload to the local message state.lib/controllers/auth_state_controller.dart (2)
6-6: Good handling of Row name collision.Hiding
Rowfrom Flutter Material to use Appwrite'sRowtype is the correct approach to resolve the naming conflict.
206-223: API migration looks correct.The migration from
getDocumenttogetRowwith updated parameter names (tableId,rowId) follows the expected TablesDB API pattern.test/controllers/edit_profile_controller_test.dart (1)
13-60: Test migration to TablesDB API looks correct.The mock setup correctly uses
MockTablesDB,getRow, andRowwith all required fields including$tableIdand$sequence. The parameter renames (tableId,rowId) are consistent with the production code.lib/controllers/onboarding_controller.dart (2)
88-131: API migration to createRow looks correct.The migration from
createDocumenttocreateRowwith updated parameter names (tableId,rowId) is consistent with the TablesDB API pattern.
148-159: Update error message check to match TablesDB API terminology.The error check references
'Invalid \documentId` param', but since the code uses TablesDB'screateRowmethod withrowIdparameter, the Appwrite SDK may now throw errors referencingrowId` instead. Verify the actual error message string returned by the SDK and update the catch condition accordingly to ensure errors are properly caught and handled.test/controllers/user_profile_controller_test.dart (2)
19-70: Mock data migration to Row is correct.The mock story data correctly uses
Rowwith all required fields including$tableIdand$sequence. The data structure aligns with the TablesDB API.
224-280: Mock setup for TablesDB interactions looks good.The mock interactions correctly use
listRows,getRow, andcreateRowwith appropriate parameter renames. TheRowListreturn type is properly used.lib/views/screens/room_chat_screen.dart (2)
119-148: Message deletion implementation looks solid.The deletion flow includes proper error handling with try/catch, user feedback via snackbar, and the
canDeletelogic correctly prevents deletion of already-deleted messages. The confirmation dialog provides good UX.
231-292: Context menu and confirmation dialog implementation is clean.The bottom sheet context menu with delete option and the confirmation dialog follow Flutter patterns. Good use of theme colors for the delete icon.
test/controllers/friends_controller_test.dart (3)
16-16: LGTM!The
@GenerateMocksannotation is correctly updated to useTablesDBinstead ofDatabases, aligning with the API migration.
72-115: Mock Row data structures correctly include required fields.The
mockFriendRowslist properly includes all requiredRowfields:$tableId,$sequence, and other model fields. The migration fromDocumenttoRowis consistent.
195-261: Test setup correctly uses TablesDB mocks.The mock setup properly configures
MockTablesDBwithgetRow,createRow,deleteRow, andupdateRowstubs. Parameter names are correctly updated totableIdandrowId.test/controllers/friend_calling_controller_test.mocks.dart (1)
1-3: Auto-generated mock file.This file is auto-generated by Mockito from annotations. The generated
MockTablesDBclass correctly implements theTablesDBinterface with Row-based method signatures.test/controllers/friend_calling_controller_test.dart (2)
36-90: Mock Row data structures correctly migrated.The mock
Rowobjects include proper$tableId,$sequence, and data fields consistent with the TablesDB API.
96-166: Test setup correctly uses MockTablesDB.The controller wiring and mock stubs are properly updated to use
TablesDBwithgetRow,updateRow, andcreateRowmethods.lib/controllers/user_profile_controller.dart (4)
15-31: Controller correctly migrated to TablesDB.The field type and constructor parameter are properly updated to use
TablesDBwith a fallback toAppwriteService.getTables().
47-69: Data fetching methods correctly use TablesDB API.
fetchUserLikedStoriesproperly useslistRowsandgetRowwithtableIdandrowIdparameters. The response access via.rowsis correct for theRowListtype.
71-101: Conversion helper updated for Row type.The
convertAppwriteDocListToStoryListmethod signature and implementation correctly handleList<Row>instead ofList<Document>. Data access viavalue.data['field']is consistent with theRowstructure.
142-178: Follow/unfollow methods correctly use createRow and deleteRow.The
followCreatorandunfollowCreatormethods properly usecreateRowanddeleteRowwithtableIdandrowIdparameters.test/controllers/auth_state_controller_test.dart (4)
14-27: Test setup correctly migrated to TablesDB.The
@GenerateMocksannotation includesTablesDB, and theAuthStateControlleris properly constructed with thetablesparameter.
29-106: Mock RowList and Row data structures are well-structured.The
mockSubscribedUserRowListandmockUpcomingRoomsRowListcorrectly useRowListcontainingRowobjects with all required fields including$tableId,$sequence, and appropriatedatapayloads.
163-208: Mock TablesDB stubs correctly configured.The stubs for
getRow,listRows, andupdateRoware properly configured. The dynamicupdateRowstub at lines 193-208 elegantly returns aRowconstructed from the invocation's named arguments.
241-300: Verification calls correctly use TablesDB API.All
verifycalls correctly referencemockTablesDB.updateRowwithtableIdandrowIdparameters, consistent with the TablesDB migration.test/controllers/change_email_controller_test.dart (2)
1-76: LGTM! Test file properly migrated to TablesDB/Row API.The test setup correctly:
- Hides
Rowfromflutter/material.dartto avoid conflicts with Appwrite'sRowtype- Uses
MockTablesDBwithlistRows,getRow, andupdateRowmethods- Constructs
Rowobjects with proper fields including$tableId,$rowId, and$sequence
78-212: Test verifications correctly updated for TablesDB API.The mock verifications properly use the new API terminology with
updateRow,tableId, androwIdparameters. Test logic remains sound.lib/utils/constants.dart (1)
34-97: Constants properly renamed to align with TablesDB terminology.The renaming from
*CollectionIdto*TableIdmaintains the same underlying string values, ensuring backward compatibility with existing database structures while aligning the codebase terminology with the new TablesDB API.test/controllers/edit_profile_controller_test.mocks.dart (1)
1-3: Auto-generated mock file - no manual review needed.This file is generated by Mockito from annotations in the corresponding test file. The changes correctly reflect the TablesDB/Row API migration from the source annotations.
test/controllers/user_profile_controller_test.mocks.dart (1)
1-3: Auto-generated mock file - no manual review needed.This file is generated by Mockito. The changes correctly reflect the TablesDB/Row API migration.
lib/controllers/upcomming_rooms_controller.dart (2)
23-57: Well-structured dependency injection constructor.The constructor pattern with optional parameters and
Get.findfallbacks enables both production use (via GetX DI) and testing (via direct injection of mocks). This is a good refactor for testability.
152-218: Appropriate error handling with fallback object.The method properly handles exceptions and returns a fallback
AppwriteUpcommingRoomwith safe defaults, preventing UI crashes while logging the error for debugging.test/controllers/explore_story_controller_test.mocks.dart (1)
55-540: Mocks migration to TablesDB/Row looks consistentThe added Row/RowList fakes and the updated
MockTablesDBmethods (listRows/createRow/getRow/upsertRow/updateRow/deleteRow/decrementRowColumn/incrementRowColumn) correctly align with the TablesDB API surface and usedatabaseId/tableId/rowIdconsistently. No changes needed.test/controllers/auth_state_controller_test.mocks.dart (1)
12-1488: Updated mocks and TablesDB migration are coherentThe added imports, Row/RowList fakes, new
MockTablesDBimplementation, and theMockClient/MockFirebaseMessagingadjustments (includingHttpMethod/ResponseTypealiases and dummy values) are internally consistent and match the expected TablesDB and Appwrite/Firebase APIs. Nothing stands out that requires modification.test/controllers/upcoming_controller_tests.mocks.dart (1)
1-1945: New mocks for upcoming_controller_tests are well-formedThe newly generated fakes and mocks (including
MockTablesDB,MockAccount,MockClient,MockFirebaseMessaging, andMockRealtime) consistently follow the existing pattern in this codebase and correctly expose the TablesDB/Row and Realtime APIs needed by tests. No adjustments needed.test/controllers/change_email_controller_test.mocks.dart (1)
53-518: TablesDB/Row mock updates for change_email tests look correctThe introduction of Row/RowList fakes and the corresponding
MockTablesDBRow-based methods (including tableId/rowId and column parameters) are consistent with the wider Databases→TablesDB migration and match the surrounding mock patterns. No further changes required.lib/l10n/app_localizations_pa.dart (1)
82-89: Technical implementation is sound.The localization implementation is well-structured:
- Correct usage of
Intl.selectLogicfor conditional translations- Proper
Intl.pluralLogicwith locale parameter for time-based strings- Dynamic string builders with parameters work correctly
- New message deletion strings (
deleteMessageTitle,deleteMessageContent,thisMessageWasDeleted,failedToDeleteMessage) are properly implementedHowever, this work should be in a separate PR focused on Punjabi localization support rather than mixed with Dependabot configuration changes.
Once the scope issue is addressed, verify the ARB file (
lib/l10n/app_pa.arb) contains matching translations and that the Flutter localization generation is configured correctly.Also applies to: 752-758, 1047-1077, 1028-1039, 1243-1255, 1310-1321
.github/dependabot.yml
Outdated
| version: 2 | ||
| updates: | ||
| # Flutter/Dart dependencies | ||
| - package-ecosystem: "pub" | ||
| directory: "/" | ||
| schedule: | ||
| interval: "weekly" | ||
| day: "monday" | ||
| time: "09:00" | ||
| open-pull-requests-limit: 5 | ||
| versioning-strategy: increase | ||
| ignore: | ||
| # Ignore major version updates | ||
| - dependency-name: "*" | ||
| update-types: ["version-update:semver-major"] | ||
| groups: | ||
| # Group Firebase-related packages together | ||
| firebase: | ||
| patterns: | ||
| - "firebase_*" | ||
| update-types: | ||
| - "minor" | ||
| - "patch" | ||
| # Group Flutter-related packages together | ||
| flutter-packages: | ||
| patterns: | ||
| - "flutter_*" | ||
| update-types: | ||
| - "minor" | ||
| - "patch" | ||
|
|
||
| # Android Gradle dependencies | ||
| - package-ecosystem: "gradle" | ||
| directory: "/android" | ||
| schedule: | ||
| interval: "weekly" | ||
| day: "monday" | ||
| time: "09:00" | ||
| open-pull-requests-limit: 3 | ||
| versioning-strategy: increase | ||
| ignore: | ||
| # Ignore major version updates | ||
| - dependency-name: "*" | ||
| update-types: ["version-update:semver-major"] |
There was a problem hiding this comment.
CRITICAL: Filename typo will prevent Dependabot from running.
The filename is depandabot.yml but GitHub Dependabot requires the exact filename .github/dependabot.yml (note the 'e' in "dependebot"). With the current typo, Dependabot will not recognize this configuration file, and automated dependency updates will not function.
Rename the file:
git mv .github/depandabot.yml .github/dependabot.ymlThe configuration itself is well-structured with appropriate grouping and versioning strategies.
🤖 Prompt for AI Agents
In .github/depandabot.yml lines 1-44 the filename is misspelled (depandabot.yml)
so Dependabot will not detect the config; rename the file to
.github/dependabot.yml (use git mv or your file explorer), commit the rename,
and push the change so GitHub can pick up the Dependabot configuration.
| tables.updateRow( | ||
| databaseId: upcomingRoomsDatabaseId, | ||
| collectionId: subscribedUserCollectionId, | ||
| documentId: subscription.$id, | ||
| tableId: subscribedUserTableId, | ||
| rowId: subscription.$id, | ||
| data: {"registrationTokens": registrationTokens}, | ||
| ); |
There was a problem hiding this comment.
Missing await on updateRow calls may cause unhandled errors.
The updateRow calls in the loops are not awaited. If an update fails, the exception won't be caught and errors won't be logged. This also applies to similar calls on lines 310, 336, and 357.
Consider awaiting these calls or collecting futures for parallel execution:
- tables.updateRow(
+ await tables.updateRow(
databaseId: upcomingRoomsDatabaseId,
tableId: subscribedUserTableId,
rowId: subscription.$id,
data: {"registrationTokens": registrationTokens},
);Alternatively, use Future.wait for parallel execution if performance is a concern.
📝 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.
| tables.updateRow( | |
| databaseId: upcomingRoomsDatabaseId, | |
| collectionId: subscribedUserCollectionId, | |
| documentId: subscription.$id, | |
| tableId: subscribedUserTableId, | |
| rowId: subscription.$id, | |
| data: {"registrationTokens": registrationTokens}, | |
| ); | |
| await tables.updateRow( | |
| databaseId: upcomingRoomsDatabaseId, | |
| tableId: subscribedUserTableId, | |
| rowId: subscription.$id, | |
| data: {"registrationTokens": registrationTokens}, | |
| ); |
🤖 Prompt for AI Agents
In lib/controllers/auth_state_controller.dart around lines 289 to 294 (and
similarly at lines ~310, ~336, ~357), the tables.updateRow calls are not awaited
which can lead to unhandled exceptions and lost error logging; change these
calls to either await the updateRow calls so each operation completes before
proceeding, or collect the returned Futures into a list and run them in parallel
with await Future.wait(futures), and wrap the awaited operations (or the
Future.wait) in try/catch to log any exceptions so failures are not swallowed.
| // delete method | ||
| Future<void> deleteMessage(String messageId) async { | ||
| try { | ||
| Message messageToDelete = messages.firstWhere( | ||
| (msg) => msg.messageId == messageId, | ||
| ); | ||
| messageToDelete = messageToDelete.copyWith(content: '', isDeleted: true); | ||
|
|
||
| await tablesDB.updateRow( | ||
| databaseId: masterDatabaseId, | ||
| tableId: chatMessagesTableId, | ||
| rowId: messageId, | ||
| data: messageToDelete.toJsonForUpload(), | ||
| ); | ||
| log('Message deleted successfully'); | ||
| } catch (e) { | ||
| log('Error deleting message: $e'); | ||
| rethrow; | ||
| } | ||
| } |
There was a problem hiding this comment.
Add defensive check for message not found in deleteMessage.
firstWhere throws StateError if no element matches. If the message was already removed from the local list or never existed, this will cause an unhandled exception that propagates due to rethrow.
Consider adding an orElse clause or using firstWhereOrNull:
Future<void> deleteMessage(String messageId) async {
try {
- Message messageToDelete = messages.firstWhere(
- (msg) => msg.messageId == messageId,
- );
+ Message? messageToDelete = messages.firstWhereOrNull(
+ (msg) => msg.messageId == messageId,
+ );
+ if (messageToDelete == null) {
+ log('Message not found locally: $messageId');
+ return;
+ }
messageToDelete = messageToDelete.copyWith(content: '', isDeleted: true);📝 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.
| // delete method | |
| Future<void> deleteMessage(String messageId) async { | |
| try { | |
| Message messageToDelete = messages.firstWhere( | |
| (msg) => msg.messageId == messageId, | |
| ); | |
| messageToDelete = messageToDelete.copyWith(content: '', isDeleted: true); | |
| await tablesDB.updateRow( | |
| databaseId: masterDatabaseId, | |
| tableId: chatMessagesTableId, | |
| rowId: messageId, | |
| data: messageToDelete.toJsonForUpload(), | |
| ); | |
| log('Message deleted successfully'); | |
| } catch (e) { | |
| log('Error deleting message: $e'); | |
| rethrow; | |
| } | |
| } | |
| // delete method | |
| Future<void> deleteMessage(String messageId) async { | |
| try { | |
| Message? messageToDelete = messages.firstWhereOrNull( | |
| (msg) => msg.messageId == messageId, | |
| ); | |
| if (messageToDelete == null) { | |
| log('Message not found locally: $messageId'); | |
| return; | |
| } | |
| messageToDelete = messageToDelete.copyWith(content: '', isDeleted: true); | |
| await tablesDB.updateRow( | |
| databaseId: masterDatabaseId, | |
| tableId: chatMessagesTableId, | |
| rowId: messageId, | |
| data: messageToDelete.toJsonForUpload(), | |
| ); | |
| log('Message deleted successfully'); | |
| } catch (e) { | |
| log('Error deleting message: $e'); | |
| rethrow; | |
| } | |
| } |
🤖 Prompt for AI Agents
In lib/controllers/room_chat_controller.dart around lines 48–67, the
deleteMessage method uses firstWhere which throws StateError when no message
matches; update the code to defensively handle a missing message by using
firstWhere with an orElse (or firstWhereOrNull from collection) to detect
absence, then if the message is null/missing log a clear message and return
early (avoid calling updateRow or rethrowing StateError); only proceed to mark
deleted and call tablesDB.updateRow when the message exists.
|
|
||
| @override | ||
| String get deleteMessageTitle => 'संदेश हटवा'; | ||
|
|
||
| @override | ||
| String get deleteMessageContent => 'आपण खरोखर हा संदेश हटवू इच्छिता का?'; | ||
|
|
||
| @override | ||
| String get thisMessageWasDeleted => 'This message was deleted'; | ||
|
|
||
| @override | ||
| String get failedToDeleteMessage => 'Failed to delete message'; | ||
| } |
There was a problem hiding this comment.
Complete the Marathi translations for all message deletion strings.
Lines 1354 and 1357 return English strings instead of Marathi translations:
thisMessageWasDeletedreturns "This message was deleted"failedToDeleteMessagereturns "Failed to delete message"
This creates an inconsistent user experience where some strings appear in Marathi while others appear in English for Marathi-speaking users.
Suggested Marathi translations:
@override
- String get thisMessageWasDeleted => 'This message was deleted';
+ String get thisMessageWasDeleted => 'हा संदेश हटवला गेला';
@override
- String get failedToDeleteMessage => 'Failed to delete message';
+ String get failedToDeleteMessage => 'संदेश हटवण्यात अयशस्वी';📝 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.
| @override | |
| String get deleteMessageTitle => 'संदेश हटवा'; | |
| @override | |
| String get deleteMessageContent => 'आपण खरोखर हा संदेश हटवू इच्छिता का?'; | |
| @override | |
| String get thisMessageWasDeleted => 'This message was deleted'; | |
| @override | |
| String get failedToDeleteMessage => 'Failed to delete message'; | |
| } | |
| @override | |
| String get deleteMessageTitle => 'संदेश हटवा'; | |
| @override | |
| String get deleteMessageContent => 'आपण खरोखर हा संदेश हटवू इच्छिता का?'; | |
| @override | |
| String get thisMessageWasDeleted => 'हा संदेश हटवला गेला'; | |
| @override | |
| String get failedToDeleteMessage => 'संदेश हटवण्यात अयशस्वी'; | |
| } |
🤖 Prompt for AI Agents
In lib/l10n/app_localizations_mr.dart around lines 1346 to 1358, two getters
return English text; update them to Marathi. Replace thisMessageWasDeleted's
value with a Marathi sentence such as "हा संदेश हटवला गेला आहे" and replace
failedToDeleteMessage's value with a Marathi sentence such as "संदेश हटविण्यात
अयशस्वी" so all deletion-related strings are consistently localized.
| // ignore: unused_import | ||
| import 'package:intl/intl.dart' as intl; | ||
| import 'app_localizations.dart'; | ||
|
|
||
| // ignore_for_file: type=lint | ||
|
|
||
| /// The translations for Panjabi Punjabi (`pa`). | ||
| class AppLocalizationsPa extends AppLocalizations { | ||
| AppLocalizationsPa([String locale = 'pa']) : super(locale); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if the Punjabi localization file exists and examine the codebase structure
if [ -d ".git" ]; then
# If in a git repo, check git log for this file
git log --oneline --follow -- lib/l10n/app_localizations_pa.dart 2>/dev/null | head -20
else
echo "Not a git repository"
fi
# Check file structure around localization files
if [ -f "lib/l10n/app_localizations_pa.dart" ]; then
echo "=== Punjabi localization file found ==="
wc -l lib/l10n/app_localizations_pa.dart
head -20 lib/l10n/app_localizations_pa.dart
fi
# List other l10n files to understand the pattern
echo "=== Localization files in project ==="
find lib/l10n -name "app_localizations_*.dart" -type f 2>/dev/null | sortRepository: AOSSIE-Org/Resonate
Length of output: 975
🏁 Script executed:
#!/bin/bash
# Check line 931 for the potential script mixing issue
echo "=== Checking line 931 for script mixing issue ==="
sed -n '930,932p' lib/l10n/app_localizations_pa.dart
# Search for any Hindi/Devanagari characters mixed in Punjabi file
echo -e "\n=== Searching for potential Devanagari characters (Hindi script) in Punjabi file ==="
grep -n "आ\|इ\|उ\|ए\|ओ\|क\|ख\|ग\|घ" lib/l10n/app_localizations_pa.dart | head -10
# Check git status to see all files in this PR
echo -e "\n=== Git status for recent changes ==="
git status
# Show git diff summary to understand scope of changes
echo -e "\n=== Recent commit details ==="
git show --stat HEAD | head -30Repository: AOSSIE-Org/Resonate
Length of output: 2381
🏁 Script executed:
#!/bin/bash
# Get more detailed git log for the last commit
echo "=== Last commit details ==="
git log -1 --name-status HEAD
echo -e "\n=== File count in commit ==="
git log -1 --name-status HEAD | grep -E "^(A|M|D)" | wc -l
echo -e "\n=== Files modified/added in commit ==="
git log -1 --name-status HEAD | grep -E "^(A|M|D)"Repository: AOSSIE-Org/Resonate
Length of output: 33034
🏁 Script executed:
#!/bin/bash
# Check what changed in main.dart and build files
echo "=== Changes in lib/main.dart ==="
git diff HEAD~1 HEAD -- lib/main.dart | head -50
echo -e "\n=== Changes in pubspec.yaml ==="
git diff HEAD~1 HEAD -- pubspec.yaml | head -50
echo -e "\n=== Check if Punjabi localization is a generated file ==="
head -1 lib/l10n/app_localizations_pa.dartRepository: AOSSIE-Org/Resonate
Length of output: 287
🏁 Script executed:
#!/bin/bash
# Get the exact context around line 931 with more lines
echo "=== Context around line 931 (lines 925-938) ==="
sed -n '925,938p' lib/l10n/app_localizations_pa.dart
# Find all instances of the problematic Hindi character
echo -e "\n=== All lines containing आवाज़ (Hindi voice) ==="
grep -n "आवाज़" lib/l10n/app_localizations_pa.dart
# Show what the correct Punjabi should be
echo -e "\n=== What it should be in Punjabi script ==="
grep -n "ਆਵਾਜ" lib/l10n/app_localizations_pa.dart | head -3Repository: AOSSIE-Org/Resonate
Length of output: 1048
Fix script mixing error in Punjabi localization at line 931.
Line 931 contains a mixed script error: 'ਰੇਜ਼ੋਨੇਟ \'ਤੇ ਹਰ ਆवਾਜ਼ ਦੀ ਕਦਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ'. The character व (Devanagari/Hindi) should be ਵ (Gurmukhi/Punjabi). Change to: 'ਰੇਜ਼ੋਨੇਟ \'ਤੇ ਹਰ ਆਵਾਜ਼ ਦੀ ਕਦਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ'.
🤖 Prompt for AI Agents
lib/l10n/app_localizations_pa.dart around line 931: there is a mixed-script
character in the Punjabi string `'ਰੇਜ਼ੋਨੇਟ \'ਤੇ ਹਰ ਆवਾਜ਼ ਦੀ ਕਦਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ'`
where Devanagari `व` was used instead of Gurmukhi `ਵ`; replace the incorrect
Devanagari character with the Gurmukhi character so the string reads `'ਰੇਜ਼ੋਨੇਟ
\'ਤੇ ਹਰ ਆਵਾਜ਼ ਦੀ ਕਦਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ'` using only Gurmukhi script.
| test('test to successfully delete a message', () async { | ||
| when( | ||
| mockDatabases.updateDocument( | ||
| databaseId: anyNamed('databaseId'), | ||
| collectionId: anyNamed('collectionId'), | ||
| documentId: anyNamed('documentId'), | ||
| data: anyNamed('data'), | ||
| permissions: anyNamed('permissions'), | ||
| ), | ||
| ).thenAnswer( | ||
| (_) async => Document( | ||
| $id: 'test-message-1', | ||
| $collectionId: chatMessagesTableId, | ||
| $databaseId: masterDatabaseId, | ||
| $createdAt: DateTime.now().toIso8601String(), | ||
| $updatedAt: DateTime.now().toIso8601String(), | ||
| $permissions: [], | ||
| $sequence: 1, | ||
| data: {}, | ||
| ), | ||
| ); | ||
|
|
||
| Message messageToDelete = messages.firstWhere( | ||
| (msg) => msg.messageId == 'test-message-1', | ||
| ); | ||
| messageToDelete = messageToDelete.copyWith(content: '', isDeleted: true); | ||
|
|
||
| await mockDatabases.updateDocument( | ||
| databaseId: masterDatabaseId, | ||
| collectionId: chatMessagesTableId, | ||
| documentId: 'test-message-1', | ||
| data: messageToDelete.toJsonForUpload(), | ||
| ); | ||
|
|
||
| verify( | ||
| mockDatabases.updateDocument( | ||
| databaseId: masterDatabaseId, | ||
| collectionId: chatMessagesTableId, | ||
| documentId: 'test-message-1', | ||
| data: argThat( | ||
| predicate<Map<String, dynamic>>( | ||
| (data) => data['content'] == '' && data['isDeleted'] == true, | ||
| ), | ||
| named: 'data', | ||
| ), | ||
| ), | ||
| ).called(1); | ||
| }); |
There was a problem hiding this comment.
Tests verify mock behavior rather than controller logic.
The test directly invokes mockDatabases.updateDocument(...) instead of calling the actual RoomChatController.deleteMessage() method. This tests the mock's stub configuration, not the controller's implementation.
Consider restructuring to test the actual controller:
- await mockDatabases.updateDocument(
- databaseId: masterDatabaseId,
- collectionId: chatMessagesTableId,
- documentId: 'test-message-1',
- data: messageToDelete.toJsonForUpload(),
- );
+ // Instantiate the actual controller with the mock
+ final controller = RoomChatController(databases: mockDatabases);
+ controller.messages = messages;
+
+ // Call the actual method under test
+ await controller.deleteMessage('test-message-1');| test('test to handle database errors', () async { | ||
| when( | ||
| mockDatabases.updateDocument( | ||
| databaseId: anyNamed('databaseId'), | ||
| collectionId: anyNamed('collectionId'), | ||
| documentId: anyNamed('documentId'), | ||
| data: anyNamed('data'), | ||
| permissions: anyNamed('permissions'), | ||
| ), | ||
| ).thenThrow(AppwriteException('Database error')); | ||
|
|
||
| Message messageToDelete = messages.firstWhere( | ||
| (msg) => msg.messageId == 'test-message-1', | ||
| ); | ||
| messageToDelete = messageToDelete.copyWith(content: '', isDeleted: true); | ||
|
|
||
| try { | ||
| await mockDatabases.updateDocument( | ||
| databaseId: masterDatabaseId, | ||
| collectionId: chatMessagesTableId, | ||
| documentId: 'test-message-1', | ||
| data: messageToDelete.toJsonForUpload(), | ||
| ); | ||
| fail('Should have thrown AppwriteException'); | ||
| } catch (e) { | ||
| expect(e, isA<AppwriteException>()); | ||
| } | ||
|
|
||
| verify( | ||
| mockDatabases.updateDocument( | ||
| databaseId: masterDatabaseId, | ||
| collectionId: chatMessagesTableId, | ||
| documentId: 'test-message-1', | ||
| data: anyNamed('data'), | ||
| ), | ||
| ).called(1); | ||
| }); |
There was a problem hiding this comment.
Same pattern issue in error handling test.
This test also calls the mock directly rather than testing how the controller handles AppwriteException propagation. The controller's error handling logic is not exercised.
| /// A class which mocks [Databases]. | ||
| /// | ||
| /// See the documentation for Mockito's code generation for more information. | ||
| class MockDatabases extends _i1.Mock implements _i4.Databases { | ||
| MockDatabases() { | ||
| _i1.throwOnMissingStub(this); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the test file for @GenerateMocks annotation and what it imports
head -100 test/controllers/room_chat_controller_test.dartRepository: AOSSIE-Org/Resonate
Length of output: 3165
🏁 Script executed:
#!/bin/bash
# Check the room_chat_controller to see what it uses
grep -n "Databases\|TablesDB" lib/controllers/room_chat_controller.dart | head -20Repository: AOSSIE-Org/Resonate
Length of output: 122
🏁 Script executed:
#!/bin/bash
# Check if test instantiates RoomChatController
grep -n "RoomChatController" test/controllers/room_chat_controller_test.dartRepository: AOSSIE-Org/Resonate
Length of output: 116
🏁 Script executed:
#!/bin/bash
# Look at the full test to see what's being tested
sed -n '14,120p' test/controllers/room_chat_controller_test.dartRepository: AOSSIE-Org/Resonate
Length of output: 3349
🏁 Script executed:
#!/bin/bash
# Check the full test file length and see if there are more tests
wc -l test/controllers/room_chat_controller_test.dart
tail -50 test/controllers/room_chat_controller_test.dartRepository: AOSSIE-Org/Resonate
Length of output: 1596
🏁 Script executed:
#!/bin/bash
# Check if TablesDB is imported in the test file
grep -n "TablesDB\|import" test/controllers/room_chat_controller_test.dart | head -15Repository: AOSSIE-Org/Resonate
Length of output: 432
Update @GenerateMocks annotation to mock TablesDB instead of Databases.
The test file uses @GenerateMocks([Databases]) from the old Appwrite API, but RoomChatController has been migrated to use TablesDB. Update the annotation to @GenerateMocks([TablesDB]) in room_chat_controller_test.dart and regenerate mocks via flutter pub run build_runner build.
🤖 Prompt for AI Agents
In test/controllers/room_chat_controller_test.mocks.dart around lines 53 to 59,
the generated mock class targets the old Appwrite Databases API; update the test
annotation in room_chat_controller_test.dart from @GenerateMocks([Databases]) to
@GenerateMocks([TablesDB]) so the mock generation targets TablesDB, then run
flutter pub run build_runner build to regenerate mocks; ensure any imports in
the test file reference TablesDB (and its package) instead of Databases and
re-run tests.
| import 'package:resonate/themes/theme_controller.dart'; | ||
| import 'package:resonate/utils/enums/room_state.dart'; | ||
|
|
||
| @GenerateMocks([Databases, Client]) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check RoomsController implementation to see what it actually uses
echo "=== RoomsController implementation ==="
rg -n "class RoomsController" -A 30 lib/controllers/rooms_controller.dart
echo -e "\n=== Check for TablesDB usage in RoomsController ==="
rg -n "TablesDB\|Databases" lib/controllers/rooms_controller.dart
echo -e "\n=== Check test file for mock generation ==="
head -30 test/controllers/rooms_controller_test.dart
echo -e "\n=== Check for TablesDB definition in codebase ==="
fd "TablesDB" --type fRepository: AOSSIE-Org/Resonate
Length of output: 2581
🏁 Script executed:
#!/bin/bash
# Check what TablesDB is and where it comes from
echo "=== Search for TablesDB definition ==="
rg -n "class TablesDB\|typedef TablesDB" -B 2 -A 5
echo -e "\n=== Check imports in rooms_controller.dart ==="
head -20 lib/controllers/rooms_controller.dart
echo -e "\n=== Check what's in test file imports ==="
head -15 test/controllers/rooms_controller_test.dart | grep -i import
echo -e "\n=== Check if TablesDB is used in test setup ==="
rg -n "TablesDB" test/controllers/rooms_controller_test.dartRepository: AOSSIE-Org/Resonate
Length of output: 1569
🏁 Script executed:
#!/bin/bash
# Check appwrite_service to understand TablesDB
echo "=== Check AppwriteService getTables method ==="
rg -n "getTables\|TablesDB" lib/services/appwrite_service.dart -B 2 -A 5
echo -e "\n=== Check what Databases and Client are used for in test ==="
rg -n "MockDatabases\|MockClient" test/controllers/rooms_controller_test.dart | head -20
echo -e "\n=== Check full test setup/initialization ==="
sed -n '29,80p' test/controllers/rooms_controller_test.dartRepository: AOSSIE-Org/Resonate
Length of output: 1743
🏁 Script executed:
#!/bin/bash
# Check appwrite package to understand TablesDB type
echo "=== Search for TablesDB type definition (might be a typedef) ==="
rg -n "TablesDB" --type dart
echo -e "\n=== Check the actual RoomsController constructor and dependencies ==="
sed -n '21,30p' lib/controllers/rooms_controller.dart
echo -e "\n=== Look for any usage of Databases in RoomsController ==="
rg -n "Databases" lib/controllers/rooms_controller.dart
echo -e "\n=== Check AppwriteService to see what getTables returns ==="
cat lib/services/appwrite_service.dart | grep -A 10 "getTables"Repository: AOSSIE-Org/Resonate
Length of output: 10039
🏁 Script executed:
#!/bin/bash
# Check if the test file actually uses MockDatabases or MockClient
echo "=== Check for usage of mocks in test file ==="
grep -n "Mock" test/controllers/rooms_controller_test.dart
echo -e "\n=== Check entire test file to see if mocks are used ==="
wc -l test/controllers/rooms_controller_test.dartRepository: AOSSIE-Org/Resonate
Length of output: 288
Update @GenerateMocks to reflect actual controller dependencies.
The test generates mocks for Databases and Client, but RoomsController uses TablesDB (from AppwriteService.getTables()) for database operations. Update the annotation to @GenerateMocks([TablesDB, Client]) to match the controller's actual dependencies, consistent with other controller tests in the codebase.
🤖 Prompt for AI Agents
In test/controllers/rooms_controller_test.dart around line 14, the
@GenerateMocks annotation incorrectly lists Databases instead of the actual
dependency TablesDB used by RoomsController; change the annotation to
@GenerateMocks([TablesDB, Client]) so the generated mocks match the controller's
real dependencies (update any imports if needed to reference TablesDB and ensure
mock generation runs).
| // Mocks generated by Mockito 5.4.6 from annotations | ||
| // in resonate/test/controllers/rooms_controller_test.dart. | ||
| // Do not manually edit this file. | ||
|
|
||
| // ignore_for_file: no_leading_underscores_for_library_prefixes | ||
| import 'dart:async' as _i6; | ||
|
|
||
| import 'package:appwrite/appwrite.dart' as _i5; | ||
| import 'package:appwrite/models.dart' as _i3; | ||
| import 'package:appwrite/src/client.dart' as _i2; | ||
| import 'package:appwrite/src/enums.dart' as _i9; | ||
| import 'package:appwrite/src/response.dart' as _i4; | ||
| import 'package:appwrite/src/upload_progress.dart' as _i8; | ||
| import 'package:mockito/mockito.dart' as _i1; | ||
| import 'package:mockito/src/dummies.dart' as _i7; | ||
|
|
||
| // ignore_for_file: type=lint | ||
| // ignore_for_file: avoid_redundant_argument_values | ||
| // ignore_for_file: avoid_setters_without_getters | ||
| // ignore_for_file: comment_references | ||
| // ignore_for_file: deprecated_member_use | ||
| // ignore_for_file: deprecated_member_use_from_same_package | ||
| // ignore_for_file: implementation_imports | ||
| // ignore_for_file: invalid_use_of_visible_for_testing_member | ||
| // ignore_for_file: must_be_immutable | ||
| // ignore_for_file: prefer_const_constructors | ||
| // ignore_for_file: unnecessary_parenthesis | ||
| // ignore_for_file: camel_case_types | ||
| // ignore_for_file: subtype_of_sealed_class | ||
| // ignore_for_file: invalid_use_of_internal_member | ||
|
|
||
| class _FakeClient_0 extends _i1.SmartFake implements _i2.Client { | ||
| _FakeClient_0(Object parent, Invocation parentInvocation) | ||
| : super(parent, parentInvocation); | ||
| } | ||
|
|
||
| class _FakeTransactionList_1 extends _i1.SmartFake | ||
| implements _i3.TransactionList { | ||
| _FakeTransactionList_1(Object parent, Invocation parentInvocation) | ||
| : super(parent, parentInvocation); | ||
| } | ||
|
|
||
| class _FakeTransaction_2 extends _i1.SmartFake implements _i3.Transaction { | ||
| _FakeTransaction_2(Object parent, Invocation parentInvocation) | ||
| : super(parent, parentInvocation); | ||
| } | ||
|
|
||
| class _FakeDocumentList_3 extends _i1.SmartFake implements _i3.DocumentList { | ||
| _FakeDocumentList_3(Object parent, Invocation parentInvocation) | ||
| : super(parent, parentInvocation); | ||
| } | ||
|
|
||
| class _FakeDocument_4 extends _i1.SmartFake implements _i3.Document { | ||
| _FakeDocument_4(Object parent, Invocation parentInvocation) | ||
| : super(parent, parentInvocation); | ||
| } | ||
|
|
||
| class _FakeResponse_5<T> extends _i1.SmartFake implements _i4.Response<T> { | ||
| _FakeResponse_5(Object parent, Invocation parentInvocation) | ||
| : super(parent, parentInvocation); | ||
| } | ||
|
|
||
| /// A class which mocks [Databases]. | ||
| /// | ||
| /// See the documentation for Mockito's code generation for more information. | ||
| class MockDatabases extends _i1.Mock implements _i5.Databases { | ||
| MockDatabases() { | ||
| _i1.throwOnMissingStub(this); | ||
| } | ||
|
|
||
| @override | ||
| _i2.Client get client => | ||
| (super.noSuchMethod( | ||
| Invocation.getter(#client), | ||
| returnValue: _FakeClient_0(this, Invocation.getter(#client)), | ||
| ) | ||
| as _i2.Client); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.TransactionList> listTransactions({List<String>? queries}) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#listTransactions, [], {#queries: queries}), | ||
| returnValue: _i6.Future<_i3.TransactionList>.value( | ||
| _FakeTransactionList_1( | ||
| this, | ||
| Invocation.method(#listTransactions, [], {#queries: queries}), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.TransactionList>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Transaction> createTransaction({int? ttl}) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#createTransaction, [], {#ttl: ttl}), | ||
| returnValue: _i6.Future<_i3.Transaction>.value( | ||
| _FakeTransaction_2( | ||
| this, | ||
| Invocation.method(#createTransaction, [], {#ttl: ttl}), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Transaction>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Transaction> getTransaction({ | ||
| required String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#getTransaction, [], { | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Transaction>.value( | ||
| _FakeTransaction_2( | ||
| this, | ||
| Invocation.method(#getTransaction, [], { | ||
| #transactionId: transactionId, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Transaction>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Transaction> updateTransaction({ | ||
| required String? transactionId, | ||
| bool? commit, | ||
| bool? rollback, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#updateTransaction, [], { | ||
| #transactionId: transactionId, | ||
| #commit: commit, | ||
| #rollback: rollback, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Transaction>.value( | ||
| _FakeTransaction_2( | ||
| this, | ||
| Invocation.method(#updateTransaction, [], { | ||
| #transactionId: transactionId, | ||
| #commit: commit, | ||
| #rollback: rollback, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Transaction>); | ||
|
|
||
| @override | ||
| _i6.Future<dynamic> deleteTransaction({required String? transactionId}) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#deleteTransaction, [], { | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<dynamic>.value(), | ||
| ) | ||
| as _i6.Future<dynamic>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Transaction> createOperations({ | ||
| required String? transactionId, | ||
| List<Map<dynamic, dynamic>>? operations, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#createOperations, [], { | ||
| #transactionId: transactionId, | ||
| #operations: operations, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Transaction>.value( | ||
| _FakeTransaction_2( | ||
| this, | ||
| Invocation.method(#createOperations, [], { | ||
| #transactionId: transactionId, | ||
| #operations: operations, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Transaction>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.DocumentList> listDocuments({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| List<String>? queries, | ||
| String? transactionId, | ||
| bool? total, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#listDocuments, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #queries: queries, | ||
| #transactionId: transactionId, | ||
| #total: total, | ||
| }), | ||
| returnValue: _i6.Future<_i3.DocumentList>.value( | ||
| _FakeDocumentList_3( | ||
| this, | ||
| Invocation.method(#listDocuments, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #queries: queries, | ||
| #transactionId: transactionId, | ||
| #total: total, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.DocumentList>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Document> createDocument({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| required String? documentId, | ||
| required Map<dynamic, dynamic>? data, | ||
| List<String>? permissions, | ||
| String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#createDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #data: data, | ||
| #permissions: permissions, | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Document>.value( | ||
| _FakeDocument_4( | ||
| this, | ||
| Invocation.method(#createDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #data: data, | ||
| #permissions: permissions, | ||
| #transactionId: transactionId, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Document>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Document> getDocument({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| required String? documentId, | ||
| List<String>? queries, | ||
| String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#getDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #queries: queries, | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Document>.value( | ||
| _FakeDocument_4( | ||
| this, | ||
| Invocation.method(#getDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #queries: queries, | ||
| #transactionId: transactionId, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Document>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Document> upsertDocument({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| required String? documentId, | ||
| required Map<dynamic, dynamic>? data, | ||
| List<String>? permissions, | ||
| String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#upsertDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #data: data, | ||
| #permissions: permissions, | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Document>.value( | ||
| _FakeDocument_4( | ||
| this, | ||
| Invocation.method(#upsertDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #data: data, | ||
| #permissions: permissions, | ||
| #transactionId: transactionId, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Document>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Document> updateDocument({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| required String? documentId, | ||
| Map<dynamic, dynamic>? data, | ||
| List<String>? permissions, | ||
| String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#updateDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #data: data, | ||
| #permissions: permissions, | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Document>.value( | ||
| _FakeDocument_4( | ||
| this, | ||
| Invocation.method(#updateDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #data: data, | ||
| #permissions: permissions, | ||
| #transactionId: transactionId, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Document>); | ||
|
|
||
| @override | ||
| _i6.Future<dynamic> deleteDocument({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| required String? documentId, | ||
| String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#deleteDocument, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<dynamic>.value(), | ||
| ) | ||
| as _i6.Future<dynamic>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Document> decrementDocumentAttribute({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| required String? documentId, | ||
| required String? attribute, | ||
| double? value, | ||
| double? min, | ||
| String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#decrementDocumentAttribute, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #attribute: attribute, | ||
| #value: value, | ||
| #min: min, | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Document>.value( | ||
| _FakeDocument_4( | ||
| this, | ||
| Invocation.method(#decrementDocumentAttribute, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #attribute: attribute, | ||
| #value: value, | ||
| #min: min, | ||
| #transactionId: transactionId, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Document>); | ||
|
|
||
| @override | ||
| _i6.Future<_i3.Document> incrementDocumentAttribute({ | ||
| required String? databaseId, | ||
| required String? collectionId, | ||
| required String? documentId, | ||
| required String? attribute, | ||
| double? value, | ||
| double? max, | ||
| String? transactionId, | ||
| }) => | ||
| (super.noSuchMethod( | ||
| Invocation.method(#incrementDocumentAttribute, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #attribute: attribute, | ||
| #value: value, | ||
| #max: max, | ||
| #transactionId: transactionId, | ||
| }), | ||
| returnValue: _i6.Future<_i3.Document>.value( | ||
| _FakeDocument_4( | ||
| this, | ||
| Invocation.method(#incrementDocumentAttribute, [], { | ||
| #databaseId: databaseId, | ||
| #collectionId: collectionId, | ||
| #documentId: documentId, | ||
| #attribute: attribute, | ||
| #value: value, | ||
| #max: max, | ||
| #transactionId: transactionId, | ||
| }), | ||
| ), | ||
| ), | ||
| ) | ||
| as _i6.Future<_i3.Document>); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if test file exists and inspect @GenerateMocks annotation
fd -t f rooms_controller_test.dart test/ 2>/dev/null | head -5Repository: AOSSIE-Org/Resonate
Length of output: 106
🏁 Script executed:
# Check if lib/controllers/rooms_controller.dart exists
fd -t f rooms_controller.dart lib/Repository: AOSSIE-Org/Resonate
Length of output: 148
🏁 Script executed:
# Get the content of the test file to see @GenerateMocks
fd -t f rooms_controller_test.dart test/ --exec head -50 {}Repository: AOSSIE-Org/Resonate
Length of output: 1798
🏁 Script executed:
# Check what APIs the controller actually uses
head -100 lib/controllers/rooms_controller.dartRepository: AOSSIE-Org/Resonate
Length of output: 3478
🏁 Script executed:
# Search for Databases or TablesDB usage in the controller
rg "TablesDB|Databases|listDocuments|listRows" lib/controllers/rooms_controller.dart -A 2Repository: AOSSIE-Org/Resonate
Length of output: 506
Critical: Mock file uses outdated Databases API instead of TablesDB.
The test file still generates mocks for the deprecated Databases API (@GenerateMocks([Databases, Client])), but the production controller in lib/controllers/rooms_controller.dart has migrated to TablesDB with the new API methods (listRows, getRow, etc.) and Row/RowList objects. This mismatch will cause tests to fail.
To fix:
- Update
@GenerateMocksintest/controllers/rooms_controller_test.dartto includeTablesDB - Regenerate mocks using
flutter pub run build_runner build - Update test expectations for
Row/RowListinstead ofDocument/DocumentList
🤖 Prompt for AI Agents
In test/controllers/rooms_controller_test.mocks.dart lines 1 to 436, the
generated mocks target the deprecated Databases API (Databases,
Document/DocumentList) but your controller now uses TablesDB (Row/RowList)
causing mismatched types; update the test's @GenerateMocks in
test/controllers/rooms_controller_test.dart to include TablesDB (and Client as
needed), re-run mock generation (flutter pub run build_runner build) so the
mocks reflect TablesDB methods (listRows/getRow/etc.), and then adjust test code
and expectations to use Row/RowList types and the new method names throughout
the tests.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/dependabot.yml (1)
1-44: Excellent! The critical filename issue has been resolved.The filename is now correctly spelled as
dependabot.yml, which means GitHub will properly detect and execute this configuration. The configuration itself is well-structured:✓ Weekly schedule on Mondays as specified
✓ Major updates properly ignored
✓ Firebase and Flutter packages grouped to prevent conflicts
✓ Appropriate PR limits and versioning strategyOptional enhancements for better PR management:
Consider adding labels and reviewers to automatically organize Dependabot PRs:
# Flutter/Dart dependencies - package-ecosystem: "pub" directory: "/" schedule: interval: "weekly" day: "monday" time: "09:00" + labels: + - "dependencies" + - "flutter" + reviewers: + - "your-team-or-username" open-pull-requests-limit: 5# Android Gradle dependencies - package-ecosystem: "gradle" directory: "/android" schedule: interval: "weekly" day: "monday" time: "09:00" + labels: + - "dependencies" + - "android" open-pull-requests-limit: 3You might also consider grouping additional common dependency patterns in the pub configuration, such as
google_*,http_*, or state management packages, depending on what's used in yourpubspec.yaml.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/dependabot.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: M4dhav
Repo: AOSSIE-Org/Resonate PR: 510
File: .github/workflows/build_and_deploy.yml:31-36
Timestamp: 2025-08-31T16:18:53.594Z
Learning: For the AOSSIE-Org/Resonate project, build system requirements like Java version setup are considered separate from dependency update PRs and should be handled in dedicated PRs focused on build system improvements.
|
Please do not raise PRs to master |
M4dhav
added
enhancement
M4dhav
left a comment
M4dhav
left a comment
There was a problem hiding this comment.
LGTM, a few changes though:
- We don't need to manage Android Deps, so that can be removed
- Point for discussion: Should we consider excluding the Appwrite SDK?
|
Will there be any additional configuration required to add Dependabot here? |
sorry, my bad. It wont happen again. |
ignore:
|
GitHub automatically runs it on schedule i guess, this should be enough. |
Charan-BS
force-pushed
the
add-depandabot
branch
from
355423e to
2577e7d
Compare
|
Try to avoid force pushes as much as possible in the future |
|
please resolve the merge conflict |
2 participants
Description
This PR adds Dependabot configuration to automate dependency updates.
Fixes #586
Type of change
Details
Checklist:
Maintainer Checklist
Summary by CodeRabbit
New Features
Documentation
Improvements
Tests
✏️ Tip: You can customize this high-level summary in your review settings.