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

[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	2192.29/s	2184.61/s	-0.4%
groupby_scan_postgres	159.60/s	159.27/s	-0.3%
index_join_postgres	706.70/s	714.18/s	+1.0%
index_join_scan_postgres	924.17/s	932.65/s	+0.9%
index_scan_postgres	33.52/s	33.40/s	-0.4%
oltp_delete_insert_postgres	906.09/s	916.33/s	+1.1%
oltp_insert	822.71/s	834.61/s	+1.4%
oltp_point_select	3885.02/s	3820.86/s	-1.7%
oltp_read_only	3711.22/s	3703.80/s	-0.2%
oltp_read_write	2736.60/s	2735.45/s	-0.1%
oltp_update_index	858.56/s	864.48/s	+0.6%
oltp_update_non_index	921.93/s	931.14/s	+0.9%
oltp_write_only	1969.05/s	1971.78/s	+0.1%
select_random_points	2249.23/s	2256.53/s	+0.3%
select_random_ranges	1684.52/s	1675.49/s	-0.6%
table_scan_postgres	33.26/s	33.86/s	+1.8%
types_delete_insert_postgres	917.57/s	905.50/s	-1.4%
types_table_scan_postgres	14.46/s	14.59/s	+0.8%

[itoqa]

Commit: 1f606f9: 13 test cases ran, 8 passed ✅, 5 additional findings ⚠️.

Summary

Coverage spans clean builds and server startup, database reads and writes, transactions, reconnects, branch isolation, concurrent inserts, sequence behavior, SQL parameter handling, and JSON compatibility. It includes both normal product flows and edge cases such as invalid definitions, rollback and restart recovery, concurrency, large numeric values, and unsupported operations.

Safe to merge — the dependency-focused PR introduced no regressions or new failures, and none of the observed application defects are attributable to this change. The unrelated medium-severity compatibility and concurrent-build findings should be tracked for later remediation but are not merge blockers for this PR.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Build	The project downloaded the upgraded modules from an empty cache, compiled the binary, and passed the full Go test suite.
✅	—	Build	The compiled server started with an isolated data directory, accepted a database connection, and returned the row that was inserted.
✅	—	Engine	Simple table changes and queries returned the expected rows and command results. The prepared-statement check was corrected to use PostgreSQL's bound query protocol, which is implemented and covered by the repository's prepared-statement tests.
✅	—	Engine	The connection recovered after a failed statement: rollback succeeded, a valid row was inserted and committed, and the row was readable after reconnecting. The prepared-step failure came from using the unsupported SQL PREPARE command instead of the supported bound-query protocol.
✅	—	Sequence	Two sessions committed 20 generated-ID inserts each. All 40 rows were present with unique identifiers from 1 through 40, and the sequence ended at 40.
✅	—	Sequence	Committed rows with IDs 1, 3, and 4 remained after restart, while the rolled-back ID 2 was absent. The next generated ID was 5, so committed sequence progress was preserved.
✅	—	Storage	The existing table and the newly created table were both still available with their rows after reconnecting.
✅	—	Storage	Switching between the two branches showed each branch's table and hid the other branch's table. Shared data stayed readable, and the foreign key on branch A remained available.
⚠️		Build	The invalid commit returned an error as expected, but the valid sibling build was canceled before it could preserve its binary. The expected behavior is for the valid build artifact to remain available even when another requested commit fails.
⚠️		Engine	The JSON number 12345678901234567890 was returned as 12345678901234567000, so its value was changed during JSON handling. The json_typeof query failed with a function-not-found error, while the array, NULL, quantified-predicate, composite, invalid-conversion, and post-error recovery checks succeeded.
⚠️		Engine	The database accepted CREATE SEQUENCE with MINVALUE 10 and MAXVALUE 1. PostgreSQL-compatible behavior should reject bounds where the minimum is greater than the maximum before storing the sequence.
⚠️		Sequence	After a sequence value was allocated, calling the current-value function failed with function not found instead of returning the last value for that sequence.
⚠️		Sequence	After the branch switch, the branch identity check returns a function-not-found error, and the branch readback does not show the committed sequence-backed data that the test needs to verify.

Additional Findings Details

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

🟡 Valid build output disappears after another build fails

• Severity: Medium
• Description: The invalid commit returned an error as expected, but the valid sibling build was canceled before it could preserve its binary. The expected behavior is for the valid build artifact to remain available even when another requested commit fails.
• Impact: When one requested commit is invalid, other valid builds may be canceled and their binaries are not produced. Teams must rerun builds separately, which blocks the concurrent build workflow.
• Steps to Reproduce:
  1. Request builds for one valid commit and one invalid commit at the same time.
  2. Wait for the invalid commit to fail during checkout.
  3. Check the output directory for the binary from the valid commit.
  4. Confirm that the temporary clone directory is cleaned but the valid binary is missing.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: In /tmp/output-agent-workspace/repo/utils/doltgres_builder/run.go, Run creates a derived context with context.WithCancel at lines 51-52 and passes the context returned by errgroup.WithContext to every goroutine at lines 66-70. errgroup.WithContext cancels that shared derived context when any goroutine returns an error, so the invalid commit's checkout failure propagates to the valid build. buildBinaries passes the shared context to builder.GitCheckoutTree at line 124, goBuild at line 137, and doltgresVersion at line 142; those operations can stop with context cancellation before the valid commit's output is complete. The output directory is created at lines 129-131 and the binary is written by goBuild through line 159, while lines 77-82 remove only the temporary clones-copies directory after all goroutines finish. That cleanup cannot restore an artifact whose build was canceled. The smallest practical fix is to give each sibling build a context that is independent of errgroup error cancellation while retaining the parent/user-interrupt cancellation, or otherwise collect sibling errors without canceling successful builds; the valid output must be allowed to finish and remain in DOLTGRES_BIN.

Evidence Package

• text/BUILD-3/BUILD-3-concurrent-build-failure.txt — 859 B
• text/BUILD-3/BUILD-3-shared-cancellation-source.txt — 2 KB

🟡 JSON values lose precision and type checks fail

• Severity: Medium
• Description: The JSON number 12345678901234567890 was returned as 12345678901234567000, so its value was changed during JSON handling. The json_typeof query failed with a function-not-found error, while the array, NULL, quantified-predicate, composite, invalid-conversion, and post-error recovery checks succeeded.
• Impact: Applications that read very large JSON numbers may receive changed values, leading to incorrect calculations or decisions. Queries that check a JSON value's type also fail instead of returning a result.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL service and create a table with JSON data.
  2. Insert or select a JSON value containing the number 12345678901234567890.
  3. Read the JSON value back and compare the number with the inserted value.
  4. Call json_typeof on a JSON scalar or container value.
  5. Check that arrays, NULL predicates, and composite values still return their expected results.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: server/functions/json.go:40-47 is the complete initJson registration list. It registers json_in, json_out, json_recv, json_send, json_build_array, and json_build_object, but no json_typeof implementation or registration. The repository's catalog cache nevertheless declares pg_catalog.json_typeof(json) at core/id/cache_function_defaults.go:2695, so name metadata exists without a callable function; this directly explains the observed function-not-found error.

server/functions/json.go:58-68 parses JSON input with goccy/go-json's json.Unmarshal into an interface value. Unlike the repository's arbitrary-precision parser in postgres/parser/json/json.go:713-735, this path does not configure number preservation before decoding. The resulting JSONDocument is returned at json.go:68, and json_out formats JSONDocument values at json.go:80-103. Decoding a 20-digit JSON number through an interface without UseNumber causes it to become a floating-point value before output, matching the observed rounded result. The smallest fixes are to preserve numeric lexemes during json_in decoding, for example by using a decoder configured to retain numbers or by routing through the existing arbitrary-precision JSON parser, and to implement/register json_typeof in the same initJson path with the existing catalog signature.

Evidence Package

• text/ENGINE-3/ENGINE-3-json-compatibility.txt — 967 B

🟡 Invalid sequence bounds are accepted

• Severity: Medium
• Description: The database accepted CREATE SEQUENCE with MINVALUE 10 and MAXVALUE 1. PostgreSQL-compatible behavior should reject bounds where the minimum is greater than the maximum before storing the sequence.
• Impact: Users can create a sequence with invalid minimum and maximum limits without receiving an error. Applications that rely on compatible database validation may continue with invalid sequence settings.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL-compatible server.
  2. Run CREATE SEQUENCE with MINVALUE 10 MAXVALUE 1 and no other unusual options.
  3. Check the command result and confirm that it returns CREATE SEQUENCE instead of an error.
  4. Create a valid sequence-backed table, insert a row, run a normal query, reconnect, and call nextval again to confirm the connection remains usable after the invalid definition attempt.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: server/ast/create_sequence.go:49-64 initializes the default bounds and parses the sequence options. Lines 151-170 validate MINVALUE and MAXVALUE only against the data type limits and choose defaults; there is no check that a supplied minimum is less than or equal to the supplied maximum. Lines 171-181 validate START against those bounds, but with no START supplied the default start is selected from the increment direction, so MINVALUE 10 MAXVALUE 1 passes through for an ascending sequence. Lines 187-204 construct the SequenceState with Minimum 10 and Maximum 1, and server/node/create_sequence.go:185-207 calls collection.CreateSequence and adds that state to the sequence tracker without another bounds-order check. The smallest practical fix is to reject an inverted pair immediately after both options and defaults are resolved, before constructing the SequenceState, with a controlled error such as MINVALUE cannot be greater than MAXVALUE. The PR diff in pr-context.json touches only go.mod and go.sum, so this application validation path is unchanged by the PR.

Evidence Package

• text/ENGINE-4/ENGINE-4-sequence-bounds.txt — 2 KB

🟡 Sequence current value lookup is unavailable

• Severity: Medium
• Description: After a sequence value was allocated, calling the current-value function failed with function not found instead of returning the last value for that sequence.
• Impact: Users who rely on the current-value function cannot read the last value allocated by a sequence in their session. Other sequence allocation and boundary behavior still works, so this affects a specific sequence workflow rather than all database use.
• Steps to Reproduce:
  1. Create a bounded ascending sequence with an increment of 1.
  2. Call nextval on the sequence so the current session has an allocated value.
  3. Call currval for that sequence.
  4. Observe that the server returns a function-not-found error instead of the value returned by nextval.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The executable sequence functions are registered in server/functions/nextval.go:30-34 and server/functions/setval.go:36-40. initNextVal registers only the text and regclass overloads named nextval, while initSetVal registers only the two setval overloads. server/functions/init.go:142 calls initNextVal and line 205 calls initSetVal, but there is no currval initializer or registration anywhere in the functions package. The only repository-wide currval definition is the catalog metadata entry at core/id/cache_function_defaults.go:957, which declares pg_catalog.currval(regclass) with built-in ID 1575 but does not provide a callable implementation. Consequently, name resolution can expose metadata for the expected built-in while execution has no registered function, producing the observed function-not-found error. The smallest practical fix is to add a currval implementation that reads the current session's sequence tracker value for the resolved sequence and register its regclass overload during function initialization, while preserving the existing nextval/setval paths.

Evidence Package

• text/SEQUENCE-1/SEQUENCE-1-currval-failure.txt — 3 KB

🟡 Branch switch loses sequence state

• Severity: Medium
• Description: After the branch switch, the branch identity check returns a function-not-found error, and the branch readback does not show the committed sequence-backed data that the test needs to verify.
• Impact: Users cannot confirm which branch is active or verify that committed sequence data follows a branch switch. The core sequence and rollback flows still work, so this does not show broad sequence failure or data loss.
• Steps to Reproduce:
  1. Create schema-qualified positive and negative sequences and tables whose default values call nextval.
  2. Set both sequence values from one session, insert rows from separate sessions, commit the intended rows, and roll back one temporary insert.
  3. Create and switch to a second branch, then run the branch identity check and read the branch-specific table.
  4. Observe that current_branch() returns function not found and the branch-specific readback contains zero rows instead of the expected committed sequence state.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The executable function catalog initializes current-database and current-schema helpers in server/functions/init.go:108-110, and initializes nextval and setval at server/functions/init.go:142 and 205, but there is no current_branch initializer or implementation anywhere in the repository. This matches the recorded ERROR: function: 'current_branch' not found at sequence2-output.txt:97. The sequence implementation itself is branch/root aware only through the current database context: server/functions/nextval.go:36-79 loads the sequence collection from ctx.GetCurrentDatabase(), obtains the current root, advances the tracker, and writes the value; server/functions/setval.go:63-139 similarly loads the current collection and working set before updating global and local sequence state. Those paths explain why cross-session setval, generated values, and rollback mostly succeed, but they do not provide the missing branch identity function. The PR file diff contains only dependency-version changes in go.mod and go.sum, so there is no changed application line to attribute to this behavior. The smallest practical fix is to register and implement current_branch() using the active session branch/ref, then add a focused branch-state test that checks both the function result and the committed branch data; the zero-row readback should also be investigated against the intended branch fork point rather than hidden by the missing function error.

Evidence Package

• text/SEQUENCE-2/SEQUENCE-2-branch-state-evidence.txt — 3 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18407	18406
Failures	23683	23684
Partial Successes1	5327	5327

	Main	PR
Successful	43.7325%	43.7301%
Failures	56.2675%	56.2699%

${\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. ↩