Looks like server ops to a doc are queued up and not applied after a client doc is destroyed

[YilinGao]

Hello, I'm working on a code collaborative editing project (like Google Doc) and I'm using ShareDB to manage updates by multiple users. Because there are more than one code file for users to update, users need to leave one doc at some time and go back to it later. But I have encountered a problem (or noticed a phenomenon) during this process:

Suppose there are 2 users, A and B, and they are both editing doc X. Then B leaves doc X, while A is still editing X (submitting a series of ops to ShareDB server). Now B comes back to doc X, and here I find the data that B's doc X has received are: the initial doc.data which is what user B left before, and then the series of ops that A submitted after B left.

With exact code:

handleUserEnterLeaveModule(leaveModule, enterModule) {
    if (leaveModule) {   // user B leaves doc X
      if (this.doc) {
        this.doc.destroy();
        this.doc.removeListener('op', this.handleSharedbUpdateRunMethod);
        this.doc = null;
      }
    }
    if (enterModule) { // user B enters doc X
      this.initSharedbDoc(enterModule);
    }
  }

initSharedbDoc(enterModule) {
    if (this.doc && this.doc.id === enterModule) return;
    this.doc = this.connection.get('module-editor-run-method', enterModule);
    this.doc.subscribe((err) => {
      if (err) throw err;
      if (!this.doc.data) {
        this.doc.create(this.codeMirror.getDoc().getValue());
      } else {
        // when user B enters doc X again, this.doc.data is not the latest version in server,
        // but where user B left before, without updates from user A
        this.codeMirror.getDoc().setValue(this.doc.data);
      }
      this.doc.on('op', this.handleSharedbUpdateRunMethod);
    });
  }

// after doc initialization, the op handler is called for every op from user A
handleSharedbUpdateRunMethod = (op, source) => {
    if (!source) {
      // update CodeMirror value according to op
    }
  };

Although in the current way my program has correct outcome, I feel it's kind of not reasonable that data from server are not up-to-date. My question is, is this the correct way that ShareDB is designed to work? If not, can anybody give any idea about how I should get it work in an expected way?

Thanks!

[gkubisa]

I think the problem is that the document is still cached in the connection after calling destroy.

When destroy is executed, the document is removed from the connection here, however, it is added straight back here, if a subscription is active at the time destroy is called.