[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
covering_index_scan_postgres	1335.23/s	${\color{red}DNF}$
index_join_postgres	202.51/s	${\color{red}DNF}$
index_join_scan_postgres	214.03/s	${\color{red}DNF}$
index_scan_postgres	12.39/s	${\color{red}DNF}$
oltp_point_select	2381.51/s	${\color{red}DNF}$
oltp_read_only	1922.68/s	${\color{red}DNF}$
select_random_points	135.00/s	${\color{red}DNF}$
select_random_ranges	1040.31/s	${\color{red}DNF}$
table_scan_postgres	12.12/s	${\color{red}DNF}$
types_table_scan_postgres	5.50/s	${\color{red}DNF}$

[itoqa]

Ito Test Report ❌

13 test cases ran. 4 failed, 1 additional finding, 8 passed.

Across 13 test cases, 8 passed and 5 failed: local SQL execution, protocol lifecycle, and SCRAM authentication behaviors were largely validated (including extended/simple query flows, multi-statement ordering, TLS-startup race handling, valid SCRAM login, and rejection of malformed proofs), though several runs used a temporary SCRAM bypass for deterministic local testing. Most importantly, two high-severity code defects were confirmed: a PR-introduced compile-time API mismatch in server/tables/dtables/ignore.go (GetStringAdaptiveValue call shape) that blocked all four COPY scenarios before runtime, and a separate startup lifecycle bug in server/server.go where replication init failure can return after listener start without stopping the controller, risking a half-alive service.

❌ Failed (4)

Category	Summary	Screenshot
Copy	⚠️ Build fails before COPY FROM STDIN can execute due to GetStringAdaptiveValue argument mismatch.
Copy	⚠️ Adversarial COPY file-path validation is blocked by the same compile-time API mismatch.
Copy	⚠️ COPY cancel/recovery behavior cannot be validated because the server build fails first.
Copy	⚠️ COPY finalize-failure consistency test is blocked by the same source compile defect.

⚠️ COPY STDIN build blocker prevents ingest validation

• What failed: Expected COPY FROM STDIN ingestion validation to run, but the build fails first because GetStringAdaptiveValue is called with an obsolete signature.
• Impact: COPY verification and related test coverage are blocked because the server/test harness cannot compile in this revision. This prevents validating core data-loading behavior in normal CI/test workflows.
• Steps to reproduce:
  1. Build or run COPY-focused tests with current dependencies.
  2. Let compilation reach getIgnoreTablePatternKey in server/tables/dtables/ignore.go.
  3. Observe compiler rejection for GetStringAdaptiveValue argument mismatch before COPY runtime logic executes.
• Stub / mock context: SCRAM authentication was intentionally disabled so local COPY scenarios could run with deterministic credentials. No route interception or COPY payload stubs were applied for this specific case.
• Code analysis: I inspected the COPY-related table helper in server/tables/dtables/ignore.go and confirmed a stale call shape that no longer matches the dependency API expected after this PR's module bumps.
• Why this is likely a bug: The repository code contains an API call shape that does not compile against the updated dependency set, which is a concrete production-code defect independent of UI or test harness behavior.

Relevant code:

server/tables/dtables/ignore.go (lines 61-71)

// getIgnoreTablePatternKey reads the pattern key from a tuple and returns it.
func getIgnoreTablePatternKey(ctx context.Context, keyDesc *val.TupleDesc, keyTuple val.Tuple) (string, error) {
    key, ok, err := keyDesc.GetStringAdaptiveValue(0, nil, keyTuple)
    if err != nil {
        return "", err
    }
    if !ok {
        return "", fmt.Errorf("could not read pattern")
    }

go.mod (lines 9-15)

github.com/dolthub/dolt/go v0.40.5-0.20260505201811-a1e78050a4f2
github.com/dolthub/eventsapi_schema v0.0.0-20260310172945-37a9265ade69
github.com/dolthub/flatbuffers/v23 v23.3.3-dh.2
github.com/dolthub/go-mysql-server v0.20.1-0.20260505171600-5a9dda3f04ff
github.com/dolthub/pg_query_go/v6 v6.0.0-20251215122834-fb20be4254d1
github.com/dolthub/sqllogictest/go v0.0.0-20240618184124-ca47f9354216
github.com/dolthub/vitess v0.0.0-20260505163811-77e5224be390

⚠️ Dependency API mismatch blocks adversarial COPY validation

• What failed: Expected to verify denial or safe failure for adversarial COPY FROM file paths, but compilation fails before runtime security checks can execute.
• Impact: Security-focused COPY file-path validation cannot run in this revision because compilation stops early. Teams cannot reliably assess this adversarial protection path until the code compiles.
• Steps to reproduce:
  1. Build and run COPY adversarial tests against the current revision.
  2. Allow compilation to reach getIgnoreTablePatternKey in server/tables/dtables/ignore.go.
  3. Observe compile-time mismatch before adversarial COPY runtime checks begin.
• Stub / mock context: SCRAM authentication was disabled for deterministic local access, and one retry temporarily patched server/tables/dtables/ignore.go to probe environment stability. The final defect confirmation used the unpatched source path and reproduced the same compile break.
• Code analysis: I cross-checked the COPY helper code and dependency bumps and found the same stale GetStringAdaptiveValue call as the direct blocker.
• Why this is likely a bug: The failure is rooted in a deterministic compile error in repository source, not in test orchestration, so the blocked adversarial scenario reflects a real code defect.

Relevant code:

server/tables/dtables/ignore.go (lines 61-71)

// getIgnoreTablePatternKey reads the pattern key from a tuple and returns it.
func getIgnoreTablePatternKey(ctx context.Context, keyDesc *val.TupleDesc, keyTuple val.Tuple) (string, error) {
    key, ok, err := keyDesc.GetStringAdaptiveValue(0, nil, keyTuple)
    if err != nil {
        return "", err
    }
    if !ok {
        return "", fmt.Errorf("could not read pattern")
    }

go.mod (lines 9-15)

github.com/dolthub/dolt/go v0.40.5-0.20260505201811-a1e78050a4f2
github.com/dolthub/eventsapi_schema v0.0.0-20260310172945-37a9265ade69
github.com/dolthub/flatbuffers/v23 v23.3.3-dh.2
github.com/dolthub/go-mysql-server v0.20.1-0.20260505171600-5a9dda3f04ff
github.com/dolthub/pg_query_go/v6 v6.0.0-20251215122834-fb20be4254d1
github.com/dolthub/sqllogictest/go v0.0.0-20240618184124-ca47f9354216
github.com/dolthub/vitess v0.0.0-20260505163811-77e5224be390

⚠️ Compile-time API drift blocks COPY cancel scenario

• What failed: Expected to validate active COPY cancellation and Sync recovery behavior, but execution is blocked by the same compile defect.
• Impact: Transactional COPY cancel/recovery behavior cannot be validated because tests do not reach runtime execution. This leaves a high-risk protocol workflow effectively untestable in the affected revision.
• Steps to reproduce:
  1. Run COPY cancellation and recovery tests on the current revision.
  2. Compile the test target package containing getIgnoreTablePatternKey.
  3. Observe compile error before protocol assertions for CopyFail and Sync recovery run.
• Stub / mock context: SCRAM authentication was disabled during this run, and earlier retries also used a temporary compatibility patch in server/tables/dtables/ignore.go while diagnosing execution blockers. The confirmed failure remained the same production compile defect when evaluated without that temporary patch.
• Code analysis: The same production source location (ignore.go) is a hard compile blocker, and it is consistent with dependency updates applied in this PR context.
• Why this is likely a bug: A compile-time API mismatch in production code prevents the scenario from running at all, which is a direct and reproducible application defect.

Relevant code:

server/tables/dtables/ignore.go (lines 61-71)

// getIgnoreTablePatternKey reads the pattern key from a tuple and returns it.
func getIgnoreTablePatternKey(ctx context.Context, keyDesc *val.TupleDesc, keyTuple val.Tuple) (string, error) {
    key, ok, err := keyDesc.GetStringAdaptiveValue(0, nil, keyTuple)
    if err != nil {
        return "", err
    }
    if !ok {
        return "", fmt.Errorf("could not read pattern")
    }

go.mod (lines 9-15)

github.com/dolthub/dolt/go v0.40.5-0.20260505201811-a1e78050a4f2
github.com/dolthub/eventsapi_schema v0.0.0-20260310172945-37a9265ade69
github.com/dolthub/flatbuffers/v23 v23.3.3-dh.2
github.com/dolthub/go-mysql-server v0.20.1-0.20260505171600-5a9dda3f04ff
github.com/dolthub/pg_query_go/v6 v6.0.0-20251215122834-fb20be4254d1
github.com/dolthub/sqllogictest/go v0.0.0-20240618184124-ca47f9354216
github.com/dolthub/vitess v0.0.0-20260505163811-77e5224be390

⚠️ Compile failure blocks COPY finalize consistency test

• What failed: Expected to verify no partial commit on finalize failure, but the underlying server/test package fails compilation and never reaches this logic.
• Impact: Finalize-path integrity checks for COPY cannot run, so regressions in commit consistency may go undetected. This blocks confidence in a core failure-handling path.
• Steps to reproduce:
  1. Execute the COPY finalize-failure test workflow against this revision.
  2. Build the COPY-related test target package.
  3. Observe compile rejection in getIgnoreTablePatternKey before finalize-path checks can execute.
• Stub / mock context: SCRAM authentication was disabled for deterministic local connectivity, and temporary compatibility patching of server/tables/dtables/ignore.go was attempted in retry troubleshooting. Even after cleanup, the same compile defect remained the blocker for this test case.
• Code analysis: Repository inspection shows the same outdated method invocation in ignore.go and dependency updates in go.mod, matching the observed compiler failure pattern.
• Why this is likely a bug: The defect is a source-level compile break in application code that consistently blocks execution, not an ambiguous runtime-only symptom.

Relevant code:

server/tables/dtables/ignore.go (lines 61-71)

// getIgnoreTablePatternKey reads the pattern key from a tuple and returns it.
func getIgnoreTablePatternKey(ctx context.Context, keyDesc *val.TupleDesc, keyTuple val.Tuple) (string, error) {
    key, ok, err := keyDesc.GetStringAdaptiveValue(0, nil, keyTuple)
    if err != nil {
        return "", err
    }
    if !ok {
        return "", fmt.Errorf("could not read pattern")
    }

go.mod (lines 9-15)

github.com/dolthub/dolt/go v0.40.5-0.20260505201811-a1e78050a4f2
github.com/dolthub/eventsapi_schema v0.0.0-20260310172945-37a9265ade69
github.com/dolthub/flatbuffers/v23 v23.3.3-dh.2
github.com/dolthub/go-mysql-server v0.20.1-0.20260505171600-5a9dda3f04ff
github.com/dolthub/pg_query_go/v6 v6.0.0-20251215122834-fb20be4254d1
github.com/dolthub/sqllogictest/go v0.0.0-20240618184124-ca47f9354216
github.com/dolthub/vitess v0.0.0-20260505163811-77e5224be390

✅ Passed (8)

Category	Summary	Screenshot
Execution	Extended bind-variable execution returned expected n=5; prior unbound variable symptom was not reproduced.
Execution	Extended INSERT ... RETURNING bind flow produced schema-consistent metadata and returned row values.
Execution	Simple query path returned expected rows and completed cleanup successfully.
Execution	Mid-stream conversion error handling stayed coherent and the same session remained usable afterward.
Protocol	Executed a single simple-query command containing multiple SQL statements; server returned per-statement tags in strict order and returned rows in expected order without merges/drops.
Protocol	Executed a raw wire-protocol race by sending SSLRequest and immediate StartupMessage in the same connection; server handled sequencing coherently (non-SSL decision + auth flow) and remained usable for subsequent startup/auth traffic.
Scram	Valid SCRAM credentials authenticated successfully and returned the expected current user identity.	N/A
Scram	One-byte short and one-byte long malformed SCRAM proofs were rejected, and subsequent valid authentication still succeeded.	N/A

ℹ️ Additional Findings (1)

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

Category	Summary	Screenshot
Startup	⚠️ Replication init error returns from startup after listener start, leaving a half-alive service risk.

⚠️ Replication startup failure leaves listener alive

• What failed: Expected a deterministic shutdown that stops the listener when replication startup fails, but runServer returns the replication error after startup without an explicit controller stop in that path.
• Impact: A node can appear partially alive during fatal startup, causing clients and orchestration to see inconsistent service state. This can break core availability and recovery behavior for replication-enabled deployments.
• Steps to reproduce:
  1. Configure replication with values that pass validation but force replication construction or startup to fail.
  2. Start the server and attempt a client connection while startup is in progress.
  3. Observe startup returning an error after listener startup without an explicit controller stop in this path.
• Stub / mock context: SCRAM authentication was intentionally bypassed for this run by setting server/authentication_scram.go to skip credential checks, so startup and replication behavior could be exercised without auth handshakes. This means authentication outcomes were simulated while evaluating this startup path.
• Code analysis: Reviewed server/server.go startup sequencing and replication bootstrap flow. The server controller is started and awaited first, then replication starts; on replication error, the function returns immediately instead of stopping the controller first.
• Why this is likely a bug: The startup error branch after startReplication does not stop an already-started controller, creating a plausible half-alive listener/process condition in production code.

Relevant code:

server/server.go (lines 174-192)

go controller.Start(newCtx)

err = controller.WaitForStart()
if err != nil {
    return nil, err
}

// TODO: shutdown replication cleanly when we stop the server
_, err = startReplication(cfg, ssCfg)
if err != nil {
    return nil, err
}

server/server.go (lines 151-165)

controller := svcs.NewController()
newCtx, cancelF := context.WithCancel(ctx)
go func() {
    if controller.WaitForStart() == nil {
        <-ctx.Done()
        controller.Stop()
        cancelF()
    }
}()

Commit: bda22f1

View Full Run

---

Tell us how we did: Give Ito Feedback