Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Wait for room stream change cache position #14269

Conversation

Fizzadar
Copy link
Contributor

@Fizzadar Fizzadar commented Oct 22, 2022

Proposed fix for race conditions between room stream change caches and invalidation over replication (see: #14158).

NOTE: this PR originally applied the wait for on device lists/device inbox stream change caches, but ran into a bunch of issues with those so leaving for a separate PR, this just focusses on rooms/events.

Signed off by Nick @ Beeper (@Fizzadar).

Pull Request Checklist

@Fizzadar Fizzadar force-pushed the wait-for-stream-change-cache-position branch from 802fde1 to 93c781c Compare October 23, 2022 15:48
@Fizzadar Fizzadar changed the title Wait for stream change cache position Wait for room stream change cache position Oct 23, 2022
@Fizzadar Fizzadar force-pushed the wait-for-stream-change-cache-position branch from 44d74ff to dbebe7f Compare October 23, 2022 20:39
This appears to have previously been done within the room depth handling
and only for local events.
@Fizzadar Fizzadar force-pushed the wait-for-stream-change-cache-position branch from dbebe7f to 9b5ef68 Compare October 23, 2022 20:42
@Fizzadar Fizzadar marked this pull request as ready for review October 23, 2022 21:48
@Fizzadar Fizzadar requested a review from a team as a code owner October 23, 2022 21:48
assert event.internal_metadata.stream_ordering is not None
self.store._events_stream_cache.entity_has_changed(
event.room_id, event.internal_metadata.stream_ordering
)
Copy link
Member

Choose a reason for hiding this comment

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

Don't we do this at

self._events_stream_cache.entity_has_changed(room_id, stream_ordering)

called from

self.store._invalidate_caches_for_event,

Copy link
Contributor Author

@Fizzadar Fizzadar Oct 25, 2022

Choose a reason for hiding this comment

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

Hm we do indeed. Could it be the async event cache changes? Specifically has this addition opened a gap here because the await call will mean the invalidation isn't handled synchronously? Nevermind the ID generator advances the token in a after_txn which always happens after the async callbacks so is safe.

I have reverted this change in 22d4ad1 leaving just the federated get_next call in update_current_state.

This is already handled as part of the invalidate caches for event callback.
@Fizzadar
Copy link
Contributor Author

Per discussion in #14158 this probably shouldn't be happening at all, but this change would at least log & address the issue pending any other fixes.

@Fizzadar
Copy link
Contributor Author

Fizzadar commented Dec 9, 2022

Closing for now in favour of fixing the lefover races.

@Fizzadar Fizzadar closed this Dec 9, 2022
@Fizzadar Fizzadar deleted the wait-for-stream-change-cache-position branch January 24, 2023 10:51
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants