apple / apple/foundationdb

Go: getting a one-time error 1039 since removal of the R/O transactions commit

Open
#11,621 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
16.7k
Forks
1.6k
Avg merge
1d 20h
Merged PRs (30d)
126

Description

# Description of the problem
With current `main`, running [this testcase](https://gist.github.com/gm42/d845c689a4c85a5cd59897497b6ff4eb) with multi-version client **disabled** leads to:
```
no initial delay
initial empty R/O tx: got read version 56590938127280 (using multiversion client = false)
second empty R/O tx: got read version 56590938127280 (using multiversion client = false)
initial delay of 0.05 seconds
initial empty R/O tx: got read version 56590938127280 (using multiversion client = false)
second empty R/O tx: got read version 56590938127280 (using multiversion client = false)
```
With multi-version client **enabled**:
```
no initial delay
initial empty R/O tx, failed to get future: FoundationDB error code 1039 (The protocol version of the cluster has changed) (using multiversion client = true)
second empty R/O tx: got read version 56591215314792 (using multiversion client = true)
initial delay of 0.05 seconds
initial empty R/O tx: got read version 56591215314792 (using multiversion client = true)
second empty R/O tx: got read version 56591215314792 (using multiversion client = true)
```

Reverting the change introduced in #11366:
```diff
--- b/bindings/go/src/fdb/database.go
+++ a/bindings/go/src/fdb/database.go
@@ -235,8 +235,9 @@ func (d Database) ReadTransact(f func(ReadTransaction) (interface{}, error)) (in

ret, e = f(tr)

- // read-only transactions are not committed and will be destroyed automatically via GC,
- // once all the futures go out of scope
+ if e == nil {
+ e = tr.Commit().Get()
+ }

return
}
```

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.

Contributor guide

Open the contributing guide

Research direction

Start by running the linked Go testcase with multi-version clients enabled and disabled, then inspect bindings/go/src/fdb/database.go and the change in #11366. Trace how network options and the first read-only transaction are initialized in the Go and C/C++ bindings. Done means the testcase no longer produces the initial FoundationDB error 1039.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, go
Domain
databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.