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

Js/sectioned notification #5926

Merged
merged 4 commits into from
Oct 19, 2022
Merged

Js/sectioned notification #5926

merged 4 commits into from
Oct 19, 2022

Conversation

ironage
Copy link
Contributor

@ironage ironage commented Oct 6, 2022

Fixes #5912

A sectioned results stores a cached map of previous state to report what changed in m_prev_section_index_to_key . This is refreshed when sections are calculated which happens if the Results::has_changed() returns true. The bug here is that if the first modification is on a linked property (changes are reported through links up to 4 layers deep) then the results has not actually changed, even though there is a change notification triggered on them. This means that calculate_sections has only run once and it doesn't have any initial values for m_prev_section_index_to_key yet. The solution here is to set the previous values to the initial sections if it is known to be the first run.

☑️ ToDos

  • 📝 Changelog update
  • 🚦 Tests (or not relevant)
  • C-API, if public C++ API changed.

@ironage ironage self-assigned this Oct 6, 2022
@cla-bot cla-bot bot added the cla: yes label Oct 6, 2022
Copy link
Member

@tgoyne tgoyne left a comment

Choose a reason for hiding this comment

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

This fix feels off to me somehow, but I couldn't come up with anything that wasn't just more complicated for no benefit.

Comment on lines 405 to 406
m_previous_key_to_index_lookup.clear();
m_prev_section_index_to_key.clear();
Copy link
Member

Choose a reason for hiding this comment

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

I think it might make more sense to assert that these are empty rather than clearing them? If they're non-empty then something's gone wrong.

Comment on lines 1603 to 1605
coordinator->on_change();

REQUIRE(callback_count == 0);
Copy link
Member

Choose a reason for hiding this comment

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

Adding a advance_and_notify(*r); and expecting one call here makes this test a bit clearer IMO. I was briefly confused into thinking that it was checking the changeset from the initial notification rather than the second notification below.

@ironage
Copy link
Contributor Author

ironage commented Oct 7, 2022

TBH, I'm not well pleased with this fix either. This was my introduction to the sectioned results code and it was difficult to get into. This fix was the minimal thing I found to solve the user's bug report, because I didn't feel like doing a redesign. I suspect there are further bugs lurking if the sectioned results computes sections based off a linked property but I don't know if we officially support that anyways.

@ironage ironage merged commit 8c07642 into master Oct 19, 2022
@ironage ironage deleted the js/sectioned-notification branch October 19, 2022 23:15
tgoyne added a commit that referenced this pull request Oct 21, 2022
…callback()

If the SectionedResults had been previously evaluated, reset_section_callback()
would leave it in an inconsistent state where
m_has_performed_initial_evalutation was false but the previous run info was
non-empty. #5926 introduced some assertions that now fail when this happens,
but I suspect the actual behavior was also broken before that.
tgoyne added a commit that referenced this pull request Oct 21, 2022
…callback() (#5965)

If the SectionedResults had been previously evaluated, reset_section_callback()
would leave it in an inconsistent state where
m_has_performed_initial_evalutation was false but the previous run info was
non-empty. #5926 introduced some assertions that now fail when this happens,
but I suspect the actual behavior was also broken before that.
tgoyne added a commit that referenced this pull request Oct 26, 2022
…nification

* origin/master: (22 commits)
  Fix a race condition in error reporting for async open (#5968)
  Updated release notes
  version bump to 12.11.0
  Fix a deadlock with simultaneous sync and nonsync commit notifications while tearing down RealmCoordinator (#5948)
  Track the last line seen and report it when there's an uncaught exception
  Verify that the same key is used when opening multiple DBs for a file
  Add stricter checks for valid reads on encrypted files
  Run core tests with encryption enabled on windows (#5967)
  Fix assertion failures after calling SectionedResults::reset_section_callback() (#5965)
  Add sync integration test for in-memory mode (#5955)
  Added realm core version to app login request (#5961)
  The client sending too much data is now reported as a ProtocolError::limits_exceeded (#5956)
  Updated release notes
  release core v12.10.0
  Fix C-API for realm_object_get_parent (#5960)
  fixed a bug in recovery when copying embedded lists with a single link property prefix in the path (#5957)
  Js/sectioned notification (#5926)
  Use named apikey callbacks
  Fix IN query with TypedLink as left operator
  Fix a use-after-free in client reset when the original RealmCoordinator is gone (#5949)
  ...
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 21, 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.

Crash when modifying linked objects of observed sectioned result
2 participants