Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RNET-1083: Add support for progress estimate on progress notifications #3479

Merged
merged 27 commits into from
Apr 16, 2024

Conversation

papafe
Copy link
Contributor

@papafe papafe commented Nov 15, 2023

This PR:

  • Adds ProgressEstimate to SyncProgress. It's a float value between 0.0 and 1.0 representing the estimate of the current progress.
  • Deprecates TransferableBytes and TransferredBytes in SyncProgress as these values are not accurate (especially for flexible sync).
  • Enable using GetProgressObservable with flexible sync.

Fixes #3478

TODO

  • Changelog entry
  • Tests (if applicable)

@papafe
Copy link
Contributor Author

papafe commented Nov 15, 2023

This is just a draft PR in case we have some discussing to do. It's also built on top of a PR in core.

@papafe
Copy link
Contributor Author

papafe commented Nov 17, 2023

I'm going to park this for now, as the core implementation is not yet finished, and we can't write reliable tests without it.

@cla-bot cla-bot bot added the cla: yes label Feb 8, 2024
@papafe papafe marked this pull request as ready for review February 8, 2024 14:53
@papafe papafe requested a review from nirinchev February 8, 2024 14:57
Copy link
Member

@nirinchev nirinchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me - I'd just prefer that we clean up the obsolete stuff in this PR already rather than merge it and have a follow-up PR that removes all the obsolete things as we prepare for 12.0

Realm/Realm/Sync/ProgressNotifications/SyncProgress.cs Outdated Show resolved Hide resolved
@papafe
Copy link
Contributor Author

papafe commented Feb 8, 2024

Completely removed obsolete

Copy link
Member

@nirinchev nirinchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, though it'd be nice to add a test that is a bit more strict about the notifications. Particularly, we should have a test for the download direction, which we don't seem to at the moment.

Realm/Realm/Sync/ProgressNotifications/SyncProgress.cs Outdated Show resolved Hide resolved
Tests/Realm.Tests/Sync/SessionTests.cs Outdated Show resolved Hide resolved
Tests/Realm.Tests/Sync/SessionTests.cs Outdated Show resolved Hide resolved
Tests/Realm.Tests/Sync/SessionTests.cs Show resolved Hide resolved
Copy link

coveralls-official bot commented Feb 8, 2024

Pull Request Test Coverage Report for Build 8630691641

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 6 of 6 (100.0%) changed or added relevant lines in 3 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.007%) to 81.021%

Totals Coverage Status
Change from base Build 8598129525: -0.007%
Covered Lines: 6790
Relevant Lines: 8232

💛 - Coveralls

@papafe
Copy link
Contributor Author

papafe commented Feb 16, 2024

This is going to get parked until the core PR on which it depends it has been merged.
What we need to do then:

  • Add tests
  • Remove bytes from progress notification

@nirinchev nirinchev changed the title Add support for progress estimate on progress notifications RNET-1083: Add support for progress estimate on progress notifications Mar 7, 2024
@nirinchev nirinchev changed the title RNET-1083: Add support for progress estimate on progress notifications RNET-1083 Add support for progress estimate on progress notifications Mar 7, 2024
@nirinchev nirinchev changed the title RNET-1083 Add support for progress estimate on progress notifications RNET-1083? Add support for progress estimate on progress notifications Mar 7, 2024
@nirinchev nirinchev changed the title RNET-1083? Add support for progress estimate on progress notifications RNET-1083: Add support for progress estimate on progress notifications Mar 7, 2024
papafe added 6 commits April 9, 2024 13:21
# Conflicts:
#	wrappers/realm-core
#	wrappers/src/async_open_task_cs.cpp
#	wrappers/src/sync_session_cs.cpp
@papafe papafe requested a review from nirinchev April 9, 2024 13:44
@papafe
Copy link
Contributor Author

papafe commented Apr 9, 2024

@nirinchev this is mergeable for me (I can fix the lint warning after your review 😁 )

/// The callback will, upon registration, store the total number of bytes to be transferred. When invoked, it will
/// always report the most up-to-date number of transferable bytes out of that original number of transferable bytes.
/// When the number of transferred bytes reaches or exceeds the number of transferable bytes, the callback will
/// The callback will be active until the current transferable bytes are transferred. When invoked, it will always report the

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a bit weird now to refer to transferred/transferable after these fields were removed. Also, it makes no sense any more for download direction. Probably, a good idea is to rephrase it in a way that it refers to snapshot committed version for upload on callback registration (that is essentially transferable bytes), and for download it is whatever server decides for the outgoing or next batch of changesets to catch up the client to the latest version.

Copy link
Contributor Author

@papafe papafe Apr 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kiburtse I agree with you, it's kinda imprecise.
Would you think the following will make sense?

The callback will be active:
- For uploads, until all the unsynced changesets available at the moment of the registration of the callback are sent to the server.
- For downloads, until the client catches up to the current server data (available at the moment of registration) or the next batch of changesets sent from the server.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nirinchev I'll fix the other two small things. I suppose this is the latest thing to agree on. Do you have input on this?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@papafe looks good to me. The only additional consideration here is that this notion of "next batch of changesets" is very sync client implementation specific. I'm not sure how familiar sdk users are with this. Maybe it also raises the expectations a bit too much since in steady state this is not the case for sure because every download message is its own batch, and in general it's not defined as of now how it should behave with flexible sync and subscriptions change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. I think I will change "changeset" to "data" to keep on the more generic side

Copy link
Member

@nirinchev nirinchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good - there's a few lint warnings you could drive-by fix.

Realm/Realm/Handles/SessionHandle.cs Show resolved Hide resolved
{
var token = (ProgressNotificationToken?)GCHandle.FromIntPtr(tokenPtr).Target;
token?.Notify(transferredBytes, transferableBytes);
// This is used to provide a reasonable progress estimate until the core work is done
double managedProgressEstimate = transferableBytes > 0.0 ? transferredBytes / transferableBytes : 0.0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If transferable is 0, shouldn't progress be 1?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes 👀

@papafe papafe merged commit cc537e6 into main Apr 16, 2024
66 of 67 checks passed
@papafe papafe deleted the fp/progress-notifications branch April 16, 2024 13:37
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for progress notifications
3 participants