Go: getting a one-time error 1039 since removal of the R/O transactions commit
- 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
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