Currently FDBSwift have native FoundationDB errors combined with custom FDBSwift errors. Native errors have errno <= 4100, whereas custom errors start from 8000 (NB: this is generally a questionable decision, and I might rethink errors system in future versions, but not likely because I wouldn't like to break API stability). Generally it doesn't lead to any errors, but in rare cases custom errno is passed to fdb_transaction_on_error function (in EventLoopFuture.checkingRetryableError extension method which does recommended error handling), which results in undefined behavior and already resulted in some tests being unstable.
Tactical solution to this situation would be to fail current future in EventLoopFuture.checkingRetryableError before passing errno to fdb_transaction_on_error in case if errno belongs to custom errors range. Additionally, respective helper vars in FDB.Error should be created.
Currently FDBSwift have native FoundationDB errors combined with custom FDBSwift errors. Native errors have errno <= 4100, whereas custom errors start from 8000 (NB: this is generally a questionable decision, and I might rethink errors system in future versions, but not likely because I wouldn't like to break API stability). Generally it doesn't lead to any errors, but in rare cases custom errno is passed to
fdb_transaction_on_errorfunction (inEventLoopFuture.checkingRetryableErrorextension method which does recommended error handling), which results in undefined behavior and already resulted in some tests being unstable.Tactical solution to this situation would be to fail current future in
EventLoopFuture.checkingRetryableErrorbefore passing errno tofdb_transaction_on_errorin case if errno belongs to custom errors range. Additionally, respective helper vars inFDB.Errorshould be created.