Jan

I think to free developers from the burden of retrying or conflict handling, IMHO there are at least the following options: * serializing writes to (specific) collections automatically, regardless of...

@mpoeter : for a single document update operation, we don't acquire a lock inside our storage engine wrapper, but RocksDB internally will track all modifications and locks the underlying keys....

@tomterl : sorry, have overlooked the action here. A colleague just pointed me at this. Will have a look today/tomorrow and get back. Thanks already!

@tomterl : thanks a lot for this PR. I tried running the Foxx tests in your branch, and the tests worked fine using ArangoDB 3.8, 3.9, 3.10 and 3.11/devel as...

@tomterl: The test failures that happened in the last build are "expected" and unrelated to the changes in this PR. I will create a separate PR to address them properly....

@tomterl : I have updated the arangod images used by the TravisCI tests, so that now the tests should pass in branches `3.8`, `3.9`, `3.10` and `devel` without having to...

With the currently released RocksDB versions, we keep running into the issue fixed by this PR. We keep seeing the write group leader hanging in a full write stop due...

Hello! It would be really awesome if this PR could get some attention, as the underlying problem is a serious issue (endless write stop, no further compactions) which affects our...

Any idea if/when this PR can considered for review? Thanks!

Btw, using `ingest_options.snapshot_consistency = false;` will probably fix this one example test, but still leads to other "gap in sequence numbers" errors in more complex use cases.