Open gm42 opened 2 weeks ago
FYI @johscheuer
I have additionally found out that when using OpenWithConnectionString
with a v6 FoundationDB cluster it causes this assert failure:
Assertion false failed @ /home/foundationdb_ci/src/oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo/foundationdb/fdbclient/MultiVersionTransaction.actor.cpp 2430:
addr2line -e libfdb_c.so-debug -p -C -f -i 0x124f75c 0x88ec6d 0x8b528b 0x8b5144 0x1299ce8 0x92ae36 0x1074e07 0x8973e4 0x7733a9 0xffffe64c36b118b4
Corresponding to:
Reference<IDatabase> newDb;
try {
newDb = connectionRecord.createDatabase(client->api);
} catch (Error& e) {
// Create error currently does not return any error except for network not initialized,
// which cannot happen at this point
ASSERT(false);
}
The client is basically stuck in the initializing
state in such case.
I am proposing to add a method for client status: https://github.com/apple/foundationdb/pull/11627
So that clients can start using the database only after initialization is complete.
Description of the problem
With current
main
, running this testcase with multi-version client disabled leads to:With multi-version client enabled:
Reverting the change introduced in #11366:
Instead we have no errors in both cases; this is an issue specific to the multi-version code, and I guess that the first commit waits for some state in the C/C++ binding to be initialized.
Could it be something related to the GRV cache?
Possible solution
Ideally when initializing network options the Go binding should wait for that initialization to complete, so that this initial 1039 error is avoided.