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

[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]

	Main	PR
Total	42090	42090
Successful	19290	19289
Failures	22800	22801
Partial Successes1	5459	5459

	Main	PR
Successful	45.8304%	45.8280%
Failures	54.1696%	54.1720%

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

subselect

QUERY:          select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);
RECEIVED ERROR: timeout during Receive

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: 8875aab: 11 test cases ran, 10 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans core data durability and consistency, including reconnects, concurrent writes, transactions, branching and merging, cleanup, administrative reopening, and full-suite behavior. It also exercises adversarial database conditions such as corruption and repair, with overall behavior healthy aside from an edge case where repair loses active merge-conflict and uncommitted-change state.

Safe to merge — the only observed failure is a high-severity but pre-existing, non-PR-attributable repair issue, with no regression or new failure linked to this change. It is a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	After the database was reopened, the changed table showed both rows and its new column. A second connection saw the same rows and columns.
✅	—	General	The administrative report clearly rejected a discoverable corrupted database, then the earlier valid database reopened and was scanned successfully.
✅	—	General	Repair stopped with a clear corruption error, and a later integrity check failed the same way. The saved reference state stayed unchanged, so the failed repair did not leave mixed references behind.
✅	—	General	Two sessions added different rows at the same time, and both rows were still present after reconnecting.
✅	—	Database	The existing database opened normally, the employee record changed from Ada to Adele, and a new connection read the saved value.
✅	—	Database	The administrative report found the getting_started and postgres databases on the first open and found them again after reopening the same data directory. Both inspections completed without corruption or stale-handle errors.
✅	—	Merge	The branch merge completed without conflicts, and both employee records remained readable afterward.
✅	—	Rev	The complete Go test suite compiled every package and finished successfully with no package failures.
✅	—	Rev	Separate sessions could not see uncommitted data, rollback removed the first row, and a later row committed successfully after a statement error.
✅	—	Rev	After cleanup, the current table still had the expected 1,990 rows, the active session stayed usable, and the earlier saved version still had all 2,000 rows.
⚠️		General	After repair, the branches and tag were present, but the conflict-state query returned no rows and the working/staged state was empty. The conflict and uncommitted state should have survived the branch repair so the merge could be completed.

Additional Findings Details

These findings are unrelated to the current changes but were observed during testing.

🟠 Repair removes active merge conflicts

• Severity: High
• Description: After repair, the branches and tag were present, but the conflict-state query returned no rows and the working/staged state was empty. The conflict and uncommitted state should have survived the branch repair so the merge could be completed.
• Impact: Users who run administrative repair on a conflicted branch can lose their uncommitted changes and conflict details. They may be unable to finish the merge and may need to recreate the lost work.
• Steps to Reproduce:
  1. Create a database with divergent branches, uncommitted working and staged changes, and an active merge conflict.
  2. Run the administrative repair command so it rewrites the affected branch commits.
  3. Read the branch, working, staged, and conflict state after repair.
  4. Check that the merge conflict and uncommitted changes are still present and describe the repaired graph.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: cmd/admin/repair.go:88-101 resolves each branch working set and captures only ws.WorkingRoot() and ws.StagedRoot(). When the repaired commit differs, cmd/admin/repair.go:112-115 calls ddb.NewBranchAtCommitAllowCaseConflict(sctx, branchRef, newHead, nil); the nil argument does not carry the existing conflict metadata through the branch replacement. The subsequent call at lines 123-128 invokes restoreWorkingSet with only the two captured roots. restoreWorkingSet at lines 167-215 repairs and writes only WithWorkingRoot and WithStagedRoot, then calls UpdateWorkingSet with the resulting working set; it never reads, repairs, compares, or restores the active conflict table/metadata. Therefore a branch update can reset the working set and discard merge-conflict metadata, while the restore path cannot recreate it. This matches the recorded post-repair state: branches and the tag remained, but the conflict query returned zero rows and the expected uncommitted state was absent. The smallest practical fix is to capture the working set's conflict metadata before NewBranchAtCommitAllowCaseConflict and pass the repaired/preserved metadata when restoring or updating the working set, including the no-root-change path when conflict metadata must be retained.

Evidence Package

• text/BF-CROSS-2/BF-CROSS-2-repair-state.txt — 4 KB

Tip

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

[coffeegoddd]

@coffeegoddd DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.43	2.43	0.0
groupby_scan_postgres	78.6	75.82	-3.54
index_join_postgres	2.22	2.22	0.0
index_join_scan_postgres	1.61	1.61	0.0
index_scan_postgres	467.3	475.79	1.82
oltp_point_select	0.37	0.36	-2.7
oltp_read_only	6.43	6.32	-1.71
select_random_points	0.7	0.7	0.0
select_random_ranges	1.01	1.01	0.0
table_scan_postgres	467.3	475.79	1.82
types_table_scan_postgres	1170.65	1191.92	1.82

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.36	3.36	0.0
oltp_read_write	13.46	13.46	0.0
oltp_update_index	3.55	3.55	0.0
oltp_update_non_index	3.25	3.25	0.0
oltp_write_only	7.04	7.04	0.0
types_delete_insert_postgres	7.17	7.17	0.0

[github-actions]

This PR has been superseded by #3251