fix: backup and restore progress updates in a more meaningful way. #3124
Conversation
|
@kl3jvi can you please fill the template with a description of how it supposed to work now? |
logic/src/jvmMain/kotlin/com/wire/kalium/logic/data/asset/KaliumFileSystemImpl.kt
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Thanks for the initiative!
We are in progress of refactoring the way we perform/restore backups, and while the progress indication isn't our top priority, it is definitely something we could easily improve :)
I just have a few concerns:
- The backpressure and cancellation issues I mentioned, so I think a Flow would be more flexible.
- You mentioned "backup and restore", but I don't see changes in the Restore part. This is fine, we can just rename the PR title/commit so the diffs match what's actually developed.
- Maybe there is another significant slow step that is being ignored during
exportToPlainDB
I think progress could at least be split into three steps:
- Exporting/Importing
- Zipping/Unzipping (covered by this PR)
- Encrypting/Decrypting (covered by this PR)
And, ideally, we should have a progress for each of these steps.
Our current exportToPlainDB is actually a single SQL query, so we are unable to track progress. However, the next version of the Backup format will be done in chunks, which should make it possible.
| }) | ||
| } finally { | ||
| databaseExporter.deleteBackupDBFile() | ||
| override suspend operator fun invoke(password: String, onProgress: (Float) -> Unit): CreateBackupResult = |
There was a problem hiding this comment.
I guess a callback works, but it could be a bit safer to instead return a Flow that emits progress.
A Flow can be configured to handle back pressure more gracefully. For example, what if the backup creation calls onProgress faster than it can be executed?
I think it would be nicer to just return a Flow<BackupProgress> instead.
And BackupProgress could be something like:
sealed interface BackupProgress {
data class Complete(val result: CreateBackupResult): BackupProgress
data class Ongoing(val progress: Float): BackupProgress
}Another argument for Flow:
if we change the implementation of CreateBackupUseCase and it runs on a different scope, this different scope would keep a reference to onProgress, which could lead to a leak.
It's easier to just return a flow and if it is cancelled, it is cancelled :)
There was a problem hiding this comment.
My initial implementation, was done using a flow. I need to ask about the iOS implementation though. The return of the actual function is Either, so changing that would require to do the same functionality in iOS.
I know that is the best approach and for sure will try to implement it.
Thanks for the input man
There was a problem hiding this comment.
iOS and Web do not use the code in :kalium:logic and they're a long way from this at the moment. They have their own code, their own databases, etc.
We are creating a Kotlin Multiplatform library for Backup that will live inside Kalium and it should be the first one.
It is gonna be a new module called backup, which we will publish as a stand-alone library fro Web and iOS.
It will not be responsible for exporting the data, but only to create the file, zip, encrypt, and reverse these operations.
Web, iOS and :kalium:logic will call this library with the data they want to backup. And call it with the file to get the restored data.
There was a problem hiding this comment.
Amazing, then i will do the refactoring of this using flow 👍🏻
| deletePreviousBackupFiles(backupFilePath) | ||
|
|
||
| val plainDBPath = | ||
| databaseExporter.exportToPlainDB(securityHelper.userDBOrSecretNull(userId))?.toPath() |
There was a problem hiding this comment.
question: Doesn't this exportToPlainDB also consume a long time?
I really don't know 😅.
This is the step that literally takes all the relevant content in the user's DB and exports it. Which can be a ton of data.
|
PR Submission Checklist for internal contributors
The PR Title
SQPIT-764The PR Description
What's new in this PR?
Issues
Progress not updating truthfully
Causes (Optional)
The current implementation was a fake progress that counted with a fixed delay even if we had a small file generated.
I tested with 1GB file compression and it is updating gracefully.
Solutions
Implemented a progress tracking system for file compression, which calculates the overall progress by combining the uncompressed and compressed data written. The progress is updated based on both the total bytes of uncompressed files and the size of the compressed output, with a weighted emphasis on the compressed data.
Dependencies (Optional)
If there are some other pull requests related to this one (e.g. new releases of frameworks), specify them here.
Needs releases with:
Testing
Test Coverage (Optional)
How to Test
Briefly describe how this change was tested and if applicable the exact steps taken to verify that it works as expected.
Notes (Optional)
Specify here any other facts that you think are important for this issue.
Attachments (Optional)
Attachments like images, videos, etc. (drag and drop in the text box)
PR Post Submission Checklist for internal contributors (Optional)
PR Post Merge Checklist for internal contributors
References
feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.