When transaction retries after a retriable error, caller cannot inspect the original error

[jessestimpson]

This is most apparent when setting a timeout on the database object.

Db = erlfdb:open(),
ok = erlfdb:set_option(Db, timeout, <<(10000):8/little-signed-integer-unit:8>>),
erlfdb:transactional(Db, fun(Tx) ->
    io:format("Last error: ~p~n", [erlfdb:get_last_error()]),
    erlfdb:wait(erlfdb:get(Tx, <<"bar">>)),
    erlfdb:set(Tx, <<"bar">>, <<"baz">>),
    timer:sleep(5500)
end).

Last error: undefined
Last error: 1007
** exception error: {erlfdb_error,1031}
     in function  erlfdb_nif:erlfdb_future_get/1
        called as erlfdb_nif:erlfdb_future_get(#Ref<0.2097654348.3325689858.17165>)
     in call from erlfdb:do_transaction/3 (/Users/jstimpson/dev/erlang/foundationdb-beam.erlfdb/src/erlfdb.erl, line 2104)
     in call from erlfdb:do_transaction/3 (/Users/jstimpson/dev/erlang/foundationdb-beam.erlfdb/src/erlfdb.erl, line 2107)

On commit, this transaction will internally fail with 1007 transaction_to_old and be retried. On the second attempt, it will fail with 1031 transaction_timed_out, which is not a retriable error, so that is raised to the caller.

The problem is that the caller cannot know that root cause of the failure was 1007 transaction_too_old, unless they instrument it with erlfdb:get_last_error(). Can erlfdb expose this information somehow?

[jessestimpson]

Maybe it would be better to swap these 2 lines?

            put(?ERLFDB_ERROR, Code),
            wait(on_error(Tx, Code), [{timeout, infinity}]),

=>

            wait(on_error(Tx, Code), [{timeout, infinity}]),
            put(?ERLFDB_ERROR, Code),

This would result in any non-retriable error never being stored in the process dict, and the most recent retriable error could be retrieved. What do other FDB clients do?

[jessestimpson]

The python client has similar behavior to us. From what I can tell, the 1007 error cannot be seen when using the decorator.

import fdb
fdb.api_version(730)

import time

db = fdb.open("/etc/fdb.cluster")

db.options.set_transaction_timeout(10000)

@fdb.transactional
def foo(tr):
    print("test")
    tr[b"bar"].wait()
    tr[b"bar"] = b"baz"
    time.sleep(5.5)

print(foo(db))

(venv) jstimpson:[~/dev/python/pyfdbtest]: python run.py
test
test
Traceback (most recent call last):
  File "/Users/jstimpson/dev/python/pyfdbtest/venv/lib/python3.11/site-packages/fdb/impl.py", line 309, in wrapper
    tr.commit().wait()
  File "/Users/jstimpson/dev/python/pyfdbtest/venv/lib/python3.11/site-packages/fdb/impl.py", line 809, in wait
    self.capi.fdb_future_get_error(self.fpointer)
  File "/Users/jstimpson/dev/python/pyfdbtest/venv/lib/python3.11/site-packages/fdb/impl.py", line 1458, in check_error_code
    raise FDBError(code)
fdb.impl.FDBError: b'Operation aborted because the transaction timed out' (1031)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/jstimpson/dev/python/pyfdbtest/run.py", line 17, in <module>
    print(foo(db))
          ^^^^^^^
  File "/Users/jstimpson/dev/python/pyfdbtest/venv/lib/python3.11/site-packages/fdb/impl.py", line 312, in wrapper
    tr.on_error(e.code).wait()
  File "/Users/jstimpson/dev/python/pyfdbtest/venv/lib/python3.11/site-packages/fdb/impl.py", line 809, in wait
    self.capi.fdb_future_get_error(self.fpointer)
  File "/Users/jstimpson/dev/python/pyfdbtest/venv/lib/python3.11/site-packages/fdb/impl.py", line 1458, in check_error_code
    raise FDBError(code)
fdb.impl.FDBError: b'Operation aborted because the transaction timed out' (1031)