This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
typing replication stream starts from stream_id 0 on reconnect #7907
Comments
I suspect this is a recent bug in the work done to split typing out of master. would be good to fix it before release. |
This was likely broken by #7869. |
erikjohnston
added a commit
that referenced
this issue
Jul 27, 2020
Handling of incoming typing stream updates from replication was not hooked up on master, effecting set ups where typing was handled on a different worker. This is really only a problem if the master process is also handling sync requests, which is unlikely for those that are at the stage of moving typing off. The other observable effect is that if a worker restarts or a replication connect drops then the typing worker will issue a `POSITION typing`, triggering master process to try and stream *all* typing updates from position 0. Fixes #7907
erikjohnston
added a commit
that referenced
this issue
Jul 27, 2020
Handling of incoming typing stream updates from replication was not hooked up on master, effecting set ups where typing was handled on a different worker. This is really only a problem if the master process is also handling sync requests, which is unlikely for those that are at the stage of moving typing off. The other observable effect is that if a worker restarts or a replication connect drops then the typing worker will issue a `POSITION typing`, triggering master process to try and stream *all* typing updates from position 0. Fixes #7907
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
After the replication stream dropped, the replication handler streamed all 5 million typing updates ever, which took 10 minutes:
The text was updated successfully, but these errors were encountered: