[auto-bump] [no-release-notes] dependency by coffeegoddd

[coffeegoddd]

☕ An Automated Dependency Version Bump PR 👑

Initial Changes

The changes contained in this PR were produced by `go get`ing the dependency.

```bash
go get github.com/dolthub/[dependency]/go@[commit]
```

[github-actions]

This PR has been superseded by #3134

[github-actions]

	Main	PR
Total	42090	42090
Successful	18936	18935
Failures	23154	23155
Partial Successes1	5447	5447

	Main	PR
Successful	44.9893%	44.9869%
Failures	55.0107%	55.0131%

${\color{red}Regressions (1)}$

random

QUERY:          (SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1);
RECEIVED ERROR: expected row count 0 but received 1

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[itoqa]

Commit: 9ca485b: 13 test cases ran, 1 failed ❌, 12 passed ✅.

Summary

The run covered core data operations, persistence across reconnects, schema and branch isolation, merges and conflict recovery, transaction handling, concurrent updates and inserts, sequence behavior, and consumer build integration. It exercised both normal workflows and edge cases involving conflicts, failures, and concurrency, with the behavioral checks otherwise healthy.

Not safe to merge yet — this PR introduces a high-severity build incompatibility that prevents the application from compiling and blocks release, even though the exercised data and version-control behaviors passed. No unrelated findings change that merge-blocking assessment.

Tests run by Ito

Result	Severity	Type	Description
❌		Rev	The dependency checks pass, but the project cannot compile because the updated library expects one more argument when cloning the Dolt source. The full test suite therefore stops at a build error instead of running to completion.
✅	—	General	Merging two different edits to the same row reported a clear conflict and rolled back safely. The final branch was clean and did not contain a half-merged value.
✅	—	General	Switching between alpha and beta returned the matching records row each time. New connections also saw only the rows from their selected schema.
✅	—	General	The table change and sequence change merged successfully from separate branches. After reconnecting, both pieces of metadata were present and the repository was clean.
✅	—	General	Core packages passed their tests, the server built successfully, and a sequence kept working after reconnecting.
✅	—	General	A conflicting merge returned a clear error instead of claiming success. Rolling back and reconnecting restored the main branch with its saved data intact.
✅	—	General	Switching branches did not carry the staged main change into the other branch. After the change was cleared, the feature branch had the expected rows and a clean status.
✅	—	General	A failed statement blocked the following version-control command until the transaction was rolled back. The retry then committed the recovered data successfully.
✅	—	General	Two sessions committed different row updates at the same time. Both commits were acknowledged, both values remained after reconnecting, and the commit history kept both changes.
✅	—	Object	The sequence stayed available after it was committed and the connection was reopened. Its start value remained 41, and the next values were 42 and 43.
✅	—	Rev	Twenty-five concurrent inserts completed successfully, and a fresh read showed 25 rows with unique IDs from 1 through 25.
✅	—	Table	Tables accepted new rows, an employee update, and a join query. The final readback returned Alicia, Bob, their teams, and only the three expected public tables.
✅	—	Version	The feature branch kept its new row separate from main until the merge. After the merge, main contained both the original row and the feature row.

Tip

Reply with @itoqa to send us feedback on this test run.

[itoqa]

Dependency update breaks the build

What failed: The dependency checks pass, but the project cannot compile because the updated library expects one more argument when cloning the Dolt source. The full test suite therefore stops at a build error instead of running to completion.

Impact · Steps · Stub / mock · Analysis · Why this is likely a bug

• Severity: High
• Impact: The application cannot be compiled or released with the updated dependency, so users cannot receive a working build from this change. Reverting the dependency or updating the affected call restores the release path.
• Steps to Reproduce:
  1. Use the dependency versions committed in go.mod.
  2. Run go mod verify and confirm the modules are valid.
  3. Run go test ./... --count=1.
  4. Observe the compile error in the Dolt source-cloning helper: the clone function receives three arguments but requires four.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The repository's go.mod line 9 was changed by this PR from Dolt pseudo-version v0.40.5-0.20260817234205-86039deef719 to v0.40.5-0.20260818190141-0c8421b85560; go.sum lines 249-250 update the matching checksums. The production repository still imports github.com/dolthub/dolt/go/performance/utils/dolt_builder in utils/doltgres_builder/run.go line 13, and Run calls builder.GitCloneBare(parentCtx, tempDir, GithubDoltgres) at line 44. The compiler diagnostic for the selected module reports have (context.Context, string, string) and want (context.Context, string, string, string), confirming an API arity mismatch. Because the changed module selection is the direct trigger and the consumer call was not updated, this is a PR-introduced build break. The targeted remediation is to pass the fourth branch argument required by the new API, using the branch intended by this clone operation; if that API migration is not ready, reverting the single dependency bump is the narrow fallback.
• Why this is likely a bug: This is a deterministic source-level incompatibility: the selected dependency is verified and matches go.mod, while the compiler rejects a concrete call in application repository code before tests can execute. The failure affects the build and release workflow rather than only a test assertion, and it has a direct, limited fix in the changed dependency integration path. No mocks, route stubs, or test-only code changes caused the mismatch.

Relevant code

go.mod:9

github.com/dolthub/dolt/go v0.40.5-0.20260818190141-0c8421b85560

utils/doltgres_builder/run.go:13-14

builder "github.com/dolthub/dolt/go/performance/utils/dolt_builder"
	"golang.org/x/sync/errgroup"

utils/doltgres_builder/run.go:43-46

// clone doltgres source
err = builder.GitCloneBare(parentCtx, tempDir, GithubDoltgres)
if err != nil {
	return err

Evidence Package

• text/REV-1/build-failure.txt — 2 KB

Copy prompt for an agent

Ito QA identified the following failure during automated PR testing. Please investigate and propose a fix.

**High severity — Dependency update breaks the build**

**What failed:** The dependency checks pass, but the project cannot compile because the updated library expects one more argument when cloning the Dolt source. The full test suite therefore stops at a build error instead of running to completion.

- **Impact:** The application cannot be compiled or released with the updated dependency, so users cannot receive a working build from this change. Reverting the dependency or updating the affected call restores the release path.
- **Steps to reproduce:**
  1. Use the dependency versions committed in go.mod.
  2. Run go mod verify and confirm the modules are valid.
  3. Run go test ./... --count=1.
  4. Observe the compile error in the Dolt source-cloning helper: the clone function receives three arguments but requires four.
- **Stub / mock content:** No stubs, mocks, or bypasses were applied for this test in the recorded run.
- **Code analysis:** The repository's go.mod line 9 was changed by this PR from Dolt pseudo-version v0.40.5-0.20260817234205-86039deef719 to v0.40.5-0.20260818190141-0c8421b85560; go.sum lines 249-250 update the matching checksums. The production repository still imports github.com/dolthub/dolt/go/performance/utils/dolt_builder in utils/doltgres_builder/run.go line 13, and Run calls builder.GitCloneBare(parentCtx, tempDir, GithubDoltgres) at line 44. The compiler diagnostic for the selected module reports have (context.Context, string, string) and want (context.Context, string, string, string), confirming an API arity mismatch. Because the changed module selection is the direct trigger and the consumer call was not updated, this is a PR-introduced build break. The targeted remediation is to pass the fourth branch argument required by the new API, using the branch intended by this clone operation; if that API migration is not ready, reverting the single dependency bump is the narrow fallback.
- **Why this is likely a bug:** This is a deterministic source-level incompatibility: the selected dependency is verified and matches go.mod, while the compiler rejects a concrete call in application repository code before tests can execute. The failure affects the build and release workflow rather than only a test assertion, and it has a direct, limited fix in the changed dependency integration path. No mocks, route stubs, or test-only code changes caused the mismatch.

**Relevant code:**

`go.mod:9`

~~~go
github.com/dolthub/dolt/go v0.40.5-0.20260818190141-0c8421b85560
~~~

`utils/doltgres_builder/run.go:13-14`

~~~go
builder "github.com/dolthub/dolt/go/performance/utils/dolt_builder"
	"golang.org/x/sync/errgroup"
~~~

`utils/doltgres_builder/run.go:43-46`

~~~go
// clone doltgres source
err = builder.GitCloneBare(parentCtx, tempDir, GithubDoltgres)
if err != nil {
	return err
~~~