Error 2042: "The value cannot be parsed as a tuple", unknown root cause

[jessestimpson]

On an EctoSchema using a Versionstamp primary key I got this one random failure out of many successful attempts. I haven't been able to reproduce the failure beyond that single time.

jstimpson:[~/dev/elixir/my_app]: mix test
===> [erlfdb] Compiling with FDB_API_VERSION=730
Compiling 2 files (.ex)
Generated my_app app
Running ExUnit with seed: 12113, max_cases: 20
Excluding tags: [:xxxxx]

...............................................................................................

  1) test turn_complete message_ids are persisted to the database (MyAppWebTest.Foo.SomeModule)
     test/my_app_web/foo/some_module_test.exs:211
     ** (ErlangError) Erlang error: {:erlfdb_error, 2042}
     code: persisted = MyApp.Tenant.list(acme, foo.id)
     stacktrace:
       (erlfdb 1.1.0) :erlfdb_nif.erlfdb_future_get(#Reference<0.2418867382.2781741057.126670>)
       (erlfdb 1.1.0) /Users/jstimpson/dev/elixir/my_app/deps/erlfdb/src/erlfdb.erl:2130: :erlfdb.do_transaction/3
       (ecto_foundationdb 0.7.3) lib/ecto_foundationdb/layer/tx.ex:96: EctoFoundationDB.Layer.Tx.transactional/2
       (ecto_foundationdb 0.7.3) lib/ecto/adapters/foundationdb/ecto_adapter_queryable.ex:404: Ecto.Adapters.FoundationDB.EctoAdapterQueryable.create_query_all_future/6
       (ecto_foundationdb 0.7.3) lib/ecto/adapters/foundationdb/ecto_adapter_queryable.ex:65: Ecto.Adapters.FoundationDB.EctoAdapterQueryable.execute/5
       (ecto 3.13.5) lib/ecto/repo/queryable.ex:241: Ecto.Repo.Queryable.execute/4
       (ecto 3.13.5) lib/ecto/repo/queryable.ex:28: Ecto.Repo.Queryable.all_by/4
       test/my_app_web/foo/some_module_test.exs:227: (test)

     The following output was logged:
     16:19:20.479 pid=<0.980.0> module=EctoFoundationDB.MigrationsPJ [notice] [EctoFoundationDB] 7964e97d-5a37-4152-9fbf-324b4b6014b9 (0) yyyyyyy => :zzzzzzz_id_index
     16:19:21.098 pid=<0.984.0> module=MyAppWeb.Foo.AwaitingApprovals [info] unhandled info in AwaitingApprovals: {:DOWN, #Reference<0.0.125955.2418867382.2781675522.183082>, :process, #PID<0.985.0>, :normal}
     16:19:21.106 pid=<0.984.0> module=MyAppWeb.Foo.Generating [info] unhandled info in Generating: {:DOWN, #Reference<0.0.125955.2418867382.2781675522.183102>, :process, #PID<0.989.0>, :normal}
     16:19:21.523 pid=<0.984.0> module=MyAppWeb.Foo.ReadyForPrompt [info] unhandled info in ReadyForPrompt: {:DOWN, #Reference<0.0.125955.2418867382.2781675522.183166>, :process, #PID<0.990.0>, :normal}

.......
Finished in 21.2 seconds (10.4s async, 10.7s sync)
105 tests, 1 failure, 2 excluded

It appears that the GetMappedRange failed due to encountering a non-tuple-encoded binary, but I have not been able to identify it, or anything about the root cause, or how to reproduce. The failure came at a random time while I was working on something unrelated to the database.

[jessestimpson]

#94 has a potential fix. The theory is that certain "mapper" code paths on the FDB server lazily parse a binary value as a tuple and other code paths parse the entire binary as a tuple. In the versionstamp case, the Default index key-value has an incomplete versionstamp in both the key and value portions. For the key, the incomplete versionstamp is resolved by set_versionstamp_key, but the value portion is untouched. (Unfortunately FDB doesn't support setting the VS in both the key and value simultaneously). Since an incomplete versionstamp-packed binary is not actually a valid tuple (it has a trailing multi-byte segment), a full tuple-decode attempt on the value would produce the provided error.

In all test paths up to this point, this is not an issue, though. So this implies that the full-tuple-decode code path in the FDB server is limited to certain cases that are hard to reproduce.