You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that when using sharedb-postgres, sometimes server produces following errors (code 5002) if ops are submitted in a high frequency ( 3 ~ 4 ops a second from different sources ) :
Uncaught Error: Op submit failed. Versions mismatched during op transform:
at Connection.handleMessage (bundle.js:16893)
at WebSocket.socket.onmessage (bundle.js:16846)
This error is gone if switching back to memory DB.
tracing the source code I found that when doing transformOp, getOps of sharedb-postgres returns incorrect range - it always returns ranges one version earlier, i.e., getOps("col", "doc", 10, 11) will give us the op with version 9.
I also tried with the patch by @billwashere in the pull request and it still had this issue.
another clue is that the version field in the op table in database is always plus 1 to the field of v in op.
so I went here and simply shift range by 1 like this:
SELECT version, operation FROM ops WHERE collection = $1 AND doc_id = $2 AND version > $3 AND version <= $4'
then it seems to have this issue fixed. Not quite sure but I guess there might be some inconsistent in versioning between sharedb and sharedb-postgres and the corresponding database field?
I've put the test code here in this repo so you can quickly verify it. It's adopted from rich-text example of sharedb itself, with a simple instruction in README.
The text was updated successfully, but these errors were encountered:
zbryikt
added a commit
to zbryikt/sharedb-wrapper
that referenced
this issue
May 24, 2020
I've noticed that when using sharedb-postgres, sometimes server produces following errors (code 5002) if ops are submitted in a high frequency ( 3 ~ 4 ops a second from different sources ) :
This error is gone if switching back to memory DB.
tracing the source code I found that when doing transformOp, getOps of sharedb-postgres returns incorrect range - it always returns ranges one version earlier, i.e., getOps("col", "doc", 10, 11) will give us the op with version 9.
I also tried with the patch by @billwashere in the pull request and it still had this issue.
another clue is that the
version
field in the op table in database is always plus 1 to the field of v in op.so I went here and simply shift range by 1 like this:
then it seems to have this issue fixed. Not quite sure but I guess there might be some inconsistent in versioning between sharedb and sharedb-postgres and the corresponding database field?
I've put the test code here in this repo so you can quickly verify it. It's adopted from rich-text example of sharedb itself, with a simple instruction in README.
The text was updated successfully, but these errors were encountered: