Applied attributes can cause apply mismatched. Needs load test coverage to replicate.

This initial comment seems irrelevant.

This is a bit of an edge case but it can happen. It only happens on very active pads (think 10s of edits a second).

To replicate.

1. Enable loadTesting.
2. Run loadTesting
3. Copy / paste the padId into the browser.

What happens

Pad wont load

What should hapen

Pad should load.

More debug info

Pad will successfully load and can be edited once Load Testing is complete If you are already on the pad no errors come and it works great.

Error is

Error: Failed assertion: mismatched apply: 10984 / 11740

Assumption

My assumption is that between the time of us delivering the pad object including the baseRev # there has been an additional change meaning that the next change fails causing mismatched apply.

Consider this scenario…

Rev # | 
1    | <-- we connect here
2    | <-- has been an edit here.
3    | <-- is the first commit we receive from the server

The logic is this:

exports.applyToText = function (cs, str) {
  var unpacked = exports.unpack(cs);
  exports.assert(str.length == unpacked.oldLen, "mismatched apply: ", str.length, " / ", unpacked.oldLen);

I think the solution is Etherpad can “request” previous revision upon receiving a revision that’s “in the future” and apply that before the latest revision. Essentially upon receiving 3 and knowing it’s at 1 it also requests [2] and applies [2] before 3 ?

I tried to create this same problem on the etherpad-cli-client with etherpad-load-test and can’t. The messages always appear to load in order. Next step is to simulate a delay between CLIENT_VARS and NEW_CHANGES and see what happens.

[JohnMcLear]

Noted @yorickreum. But if I can fix this issue it’s probable/possible it will fix your issue. The mismatched apply is essentially a race condition that I need to remedy and this issues bug fix will hopefully cover all eventualities of that race condition happening irrespective of the cause.

[JohnMcLear]

@Oremountainflorian I’d be tempted to suggest testing without plugins to see if it continues.

Within the 1 minute of the error persisting did you attempt to refresh your browser? Changesets are not stored persistently so it makes no sense that a refresh of low activity did not fix. I feel some plugin fuckery could be afoot