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.
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
versionfield 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.