feat: Remove auto-retry confirmation for messages#4513
Conversation
This commit removes the user-facing manual retry confirmation dialog and associated logic. The key changes are: - Deleted `RetryConfirmationDialog.kt` and its usage in the message screen. - Removed `ServiceRepositoryRetryTest.kt` as the tested functionality is no longer present. - Removed retry-related logic and state from `ServiceRepository`, `MessageViewModel`, and `MeshDataHandler`. This change simplifies the user experience by removing the prompt to confirm message retries, streamlining the message-sending process. Signed-off-by: James Rich <2199651+jamesarich@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Removes the app’s client-side “confirm retry” UX and the associated retry-management plumbing, simplifying message sending and relying on firmware retry behavior instead.
Changes:
- Deletes the Compose
RetryConfirmationDialogand removes retry-event observation/handling from the message screen + view model. - Removes
ServiceRepositoryretry API/state and associated unit tests. - Removes MAX_RETRANSMIT-triggered client retry logic from
MeshDataHandlerand updates related UI to stop showing retry counts.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| feature/messaging/src/main/kotlin/org/meshtastic/feature/messaging/component/RetryConfirmationDialog.kt | Removes the retry confirmation dialog UI entirely. |
| feature/messaging/src/main/kotlin/org/meshtastic/feature/messaging/MessageViewModel.kt | Drops retry event exposure and UI response method. |
| feature/messaging/src/main/kotlin/org/meshtastic/feature/messaging/MessageListPaged.kt | Removes retry count/max retry params from message status dialog usage. |
| feature/messaging/src/main/kotlin/org/meshtastic/feature/messaging/Message.kt | Removes retry-event collection and dialog presentation from MessageScreen. |
| feature/messaging/src/main/kotlin/org/meshtastic/feature/messaging/DeliveryInfoDialog.kt | Removes retry count display and parameters from DeliveryInfo. |
| core/service/src/test/kotlin/org/meshtastic/core/service/ServiceRepositoryRetryTest.kt | Removes tests tied to deleted ServiceRepository retry functionality. |
| core/service/src/main/kotlin/org/meshtastic/core/service/ServiceRepository.kt | Removes retry event model and retry request/response APIs. |
| app/src/test/java/com/geeksville/mesh/service/MeshDataHandlerTest.kt | Removes tests that asserted retry-event behavior on MAX_RETRANSMIT. |
| app/src/main/java/com/geeksville/mesh/service/MeshDataHandler.kt | Removes client-side retry behavior on MAX_RETRANSMIT; keeps status/broadcast handling. |
Comments suppressed due to low confidence (1)
app/src/main/java/com/geeksville/mesh/service/MeshDataHandler.kt:484
handleAckNak()behavior forRouting.Error.MAX_RETRANSMITchanged (the previous client-side retry path is gone and messages now fall through toMessageStatus.ERROR). There’s no remaining unit test coverage for this ack/nak path, so it’s easy to regress; consider adding a test asserting that MAX_RETRANSMIT results in an ERROR status update (and expected broadcast/update calls).
val m =
when {
isAck && (fromId == p?.data?.to || fromId == reaction?.to) -> MessageStatus.RECEIVED
isAck -> MessageStatus.DELIVERED
else -> MessageStatus.ERROR
| fun DeliveryInfo( | ||
| title: StringResource, | ||
| resendOption: Boolean, | ||
| text: StringResource? = null, | ||
| relayNodeName: String? = null, | ||
| relays: Int = 0, |
There was a problem hiding this comment.
DeliveryInfo() no longer accepts retryCount/maxRetries, but there are still call sites passing these args (e.g. feature/messaging/.../component/Reaction.kt around the DeliveryInfo( call). This will fail compilation; please update remaining call sites to match the new signature.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4513 +/- ##
==========================================
- Coverage 11.66% 11.25% -0.41%
==========================================
Files 424 424
Lines 14545 14432 -113
Branches 2414 2397 -17
==========================================
- Hits 1696 1625 -71
+ Misses 12533 12508 -25
+ Partials 316 299 -17 ☔ View full report in Codecov by Sentry. |
This commit removes the call to `cancelPendingRetries()` from the `onDestroy` method in `MeshService`. It also removes the `retryCount` and `maxRetries` properties from the Reaction status dialog in the messaging feature. Signed-off-by: James Rich <2199651+jamesarich@users.noreply.github.com>
This commit removes the message retry logic and associated fields from the database and data models. The `retry_count` column has been dropped from the `packet` and `reactions` tables. String resources and UI elements related to message retries have also been removed, as this functionality is now obsolete. Specific changes: - Removed `retry_count` from `DataPacket` and `Message` data classes. - Created a database migration (v33 to v34) to delete the `retry_count` column from the `packet` and `reactions` tables. - Updated database schema to version 34. - Removed retry-related strings from `strings.xml`. - Removed retry count display from the `DeliveryInfoDialog`. - Cleaned up related test files and logging. Signed-off-by: James Rich <2199651+jamesarich@users.noreply.github.com>
This commit removes the user-facing retry confirmation dialog and associated logic.
The key changes are:
RetryConfirmationDialog.ktand its usage in the message screen.ServiceRepositoryRetryTest.ktas the tested functionality is no longer present.ServiceRepository,MessageViewModel, andMeshDataHandler.This change simplifies the user experience by removing the prompt to confirm message retries, streamlining the message-sending process.
The firmware already has retry capabilities, that could be made more robust - but shouldn't have the client complicating things.
Resolves complaints on #4124