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

RCORE-2225 Loosen the FLX download progress test assertions to work with QBSv2 #7953

Open
wants to merge 2 commits into
base: tg/download-completion-on-client-reset
Choose a base branch
from

Conversation

tgoyne
Copy link
Member

@tgoyne tgoyne commented Aug 5, 2024

With QBSv2 the progress reported when a client reconnects after offline writes is progress through a history scan rather than download progress, so we can't make as strong of assertions about what the expected values are.

@tgoyne tgoyne self-assigned this Aug 5, 2024
@cla-bot cla-bot bot added the cla: yes label Aug 5, 2024
@tgoyne tgoyne force-pushed the tg/download-completion-on-client-reset branch from 329c1c6 to 7e20b9f Compare August 5, 2024 16:27
Copy link

coveralls-official bot commented Aug 5, 2024

Pull Request Test Coverage Report for Build thomas.goyne_493

Details

  • 15 of 22 (68.18%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall first build on tg/qbsv2-progress-test at 91.09%

Changes Missing Coverage Covered Lines Changed/Added Lines %
test/object-store/sync/session/progress_notifications.cpp 15 22 68.18%
Totals Coverage Status
Change from base Build thomas.goyne_492: 91.1%
Covered Lines: 217409
Relevant Lines: 238674

💛 - Coveralls

Comment on lines -1346 to +1333
double expected_step = (1.0 - entries.front()) / (size - 1);
for (size_t i = 1; i < size; ++i) {
double expected_step = 1.0 / size;
for (size_t i = 0; i < size; ++i) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we always assume that the first entry in the list is 0?
What if the progress notification was registered while the transfer has already been started and the first one or more progress items were missed?
(I am thinking of one of my planned test cases for the client reset progress notifications, where the download callback is registered while the fresh realm download is already in progress).

Copy link
Member Author

Choose a reason for hiding this comment

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

The current tests all register the notification before doing anything which would produce notifications. Tests in the future which do something different will need different checks.

Copy link
Contributor

Choose a reason for hiding this comment

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

SGTM - thanks

@tgoyne tgoyne force-pushed the tg/download-completion-on-client-reset branch 3 times, most recently from c78df18 to edc1174 Compare August 9, 2024 16:05
@tgoyne tgoyne force-pushed the tg/download-completion-on-client-reset branch from edc1174 to 0857d0e Compare August 9, 2024 18:49
With QBSv2 the progress reported when a client reconnects after offline writes
is progress through a history scan rather than download progress, so we can't
make as strong of assertions about what the expected values are.
@tgoyne tgoyne force-pushed the tg/download-completion-on-client-reset branch from 0857d0e to 80604f8 Compare August 9, 2024 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants