allow querying column or sql value with star expr and add client tests

[jennifersp]

No description provided.

[github-actions]

	Main	PR
covering_index_scan_postgres	1848.90/s	1855.04/s	+0.3%
groupby_scan_postgres	135.97/s	136.70/s	+0.5%
index_join_postgres	653.64/s	648.58/s	-0.8%
index_join_scan_postgres	800.50/s	804.71/s	+0.5%
index_scan_postgres	24.71/s	24.74/s	+0.1%
oltp_delete_insert_postgres	800.04/s	769.34/s	-3.9%
oltp_insert	685.81/s	689.86/s	+0.5%
oltp_point_select	2897.79/s	2873.88/s	-0.9%
oltp_read_only	2874.94/s	2882.30/s	+0.2%
oltp_read_write	2272.77/s	2287.46/s	+0.6%
oltp_update_index	712.27/s	707.40/s	-0.7%
oltp_update_non_index	745.56/s	750.94/s	+0.7%
oltp_write_only	1716.79/s	1712.33/s	-0.3%
select_random_points	1858.13/s	1852.01/s	-0.4%
select_random_ranges	1080.54/s	1069.77/s	-1.0%
table_scan_postgres	22.96/s	23.21/s	+1.0%
types_delete_insert_postgres	758.27/s	763.32/s	+0.6%
types_table_scan_postgres	7.86/s	8.03/s	+2.1%

[itoqa]

Commit: ce1dd3d: 10 test cases ran, 3 failed ❌, 6 passed ✅, 1 additional finding ⚠️.

Summary

The run covered database client compatibility across multiple languages, including normal query workflows, rebuild stability checks, and dependency drift behavior, and most happy-path flows remained stable. It also exercised adversarial input and failure-path behavior, where newly changed connection and reactive execution paths showed serious safety and consistency regressions.

Not safe to merge yet — this PR appears to introduce multiple high-severity failures in changed code paths, including security-sensitive input handling and non-atomic failure behavior that can leave inconsistent state. A separate medium-severity parallel test setup issue appears pre-existing and is a caveat, but the newly introduced high-severity defects are the merge blocker.

Tests run by Ito

Result	Severity	Type	Description
❌		Connection	The adversarial connection attempt was expected to fail safely, but the test run shows successful connection and execution when a username contains an extra UID token.
❌		Connection	The ODBC workflow exits on the first failing Dolt statement, but previously executed Dolt statements are not rolled back or cleaned up. Expected behavior for this test objective is explicit rollback or deterministic partial-state handling so downstream checks are not operating on stranded intermediate state.
❌		Reactive	The sequence has no transaction or reset boundary, so exceptions raised by late assertions occur after earlier mutations have already been committed.
✅	—	Connection	The ODBC happy-path flow passed: the bats lane exited 0 and confirmed baseline select/insert plus Dolt log and table-count assertions.
✅	—	Engine	Projection queries for plain columns, star projection, and mixed expressions returned expected column/value shapes with no regression observed.
✅	—	Engine	Two full postgres-client-tests build and run cycles (baseline and --pull --no-cache) both passed all 21 lanes, and both dependency snapshots and suite outputs matched with no drift reproduced.
✅	—	Legacy	The RPostgreSQL compatibility lane completed successfully and confirmed the expected baseline query behavior and Dolt commit-count checks.
✅	—	Prepared	The C++ libpqxx client flow built and ran successfully, including prepared statements (Parse/Bind/Execute) and expected count checks for both dolt_log and table rows.
✅	—	Reactive	The run was blocked before the R2DBC lane could execute because Maven Central repeatedly returned HTTP 429 while resolving build plugins, so this outcome reflects external dependency throttling rather than an application-code defect.
⚠️		Harness	Port allocation is not concurrency-safe: definePORT computes a deterministic candidate from $$ and attempts to check occupancy, but the check greps for $attemptedPORT (undefined) instead of the computed candidate.

Additional Findings Details

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

🟡 Parallel CI jobs can select the same client-test port and one server fails to bind

• Severity: Medium
• Description: Port allocation is not concurrency-safe: definePORT computes a deterministic candidate from $$ and attempts to check occupancy, but the check greps for $attemptedPORT (undefined) instead of the computed candidate.
• Impact: Concurrent jobs can select the same port and one server may fail to start with a bind error, causing a CI run to stall or lose one test execution. This affects parallel test setup reliability rather than production user data.
• Steps to Reproduce:
  1. Launch two postgres-client-tests jobs concurrently on the same host so both execute setup_doltgres_repo at nearly the same time.
  2. Let each job call definePORT and continue directly into doltgres startup.
  3. Observe both jobs selecting the same candidate port and one job failing startup with a port already in use bind error.
• Stub / mock content: The run disabled authentication for local SQL flow setup and used a local build fallback for the R2DBC artifact after dependency fetch instability; these setup adjustments do not change the definePORT allocation logic under test.
• Code Analysis: In helpers.bash:40-42, definePORT computes getPORT but checks lsof output with grep $attemptedPORT, so the probe is disconnected from the candidate and can report available even when the candidate is already in use. start_doltgres_server() assigns PORT=$(definePORT) and immediately starts doltgres on that port, and setup_doltgres_repo() always executes this path before each test. The smallest practical fix is to probe the actual candidate variable (getPORT), quote it, and retry/continue when occupied so parallel runs cannot race into duplicate binds.

Evidence Package

• text/HARNESS-1/HARNESS-1-parallel-host-network-contention.txt — 2 KB
• text/HARNESS-1/HARNESS-1-defineport-occupancy-probe.txt — 974 B

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18270	18270
Failures	23820	23820
Partial Successes1	5334	5334

	Main	PR
Successful	43.4070%	43.4070%
Failures	56.5930%	56.5930%

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]

Ito Diff Report — ce1dd3d → 4c3e671: 18 test cases ran, 0 regressions ❌, 2 new failures ❌, 3 still failing ❌, 1 fixed ✅, 11 passing ✅, 1 additional findings ⚠️.

Diff Summary

This diff run surfaced

Coverage spanned end-to-end database client behavior across multiple language paths, including normal workflows, rebuild/regression stability checks, and edge-case handling like malformed inputs and mid-flow failures. Overall behavior is mostly stable on core happy paths, but some failure-handling and input-validation paths still produce inconsistent or brittle outcomes.

Merge with caution — this PR introduces medium-severity reliability issues in newly added client-flow code, specifically around graceful input handling and state safety when a sequence fails partway through. Several other failures were also observed but are marked as pre-existing, so they are important backlog risk rather than direct blockers from this change.

Tests run by Ito

Result	State	Severity	Type	Description
❌	❌ New Failure		Postgrex	The workflow aborts on the first query error via strict pattern matching, but prior mutating statements already succeeded and remain committed, leaving a partially applied Dolt state.
❌	❌ New Failure		Postgrex	Malformed or out-of-range port input is not handled by explicit argument validation and instead terminates through raw conversion/runtime exit paths.
❌	❌->❌ Still Failing		Connection	The connection attempt consumes injected attributes from argv (for example Database=template1) instead of rejecting or escaping separators, so behavior changes from literal authentication input to attribute injection.
❌	❌->❌ Still Failing		Connection	The client executes mutating Dolt statements sequentially and exits on the first SQL error, without rollback or compensating cleanup for already-applied statements.
❌	❌->❌ Still Failing		Reactive	The first run fails late after performing inserts and Dolt workflow mutations, and the immediate retry fails earlier because leftover state changes the result of the initial pk assertion.
✅	❌->✅ Fixed	—	Harness	Two postgres-client-tests containers were run concurrently and both completed successfully without bind or connectivity failures.
✅	Passing	—	Engine	The targeted Go regression subtest passed for plain star, mixed literal-plus-star, and duplicated-name projection queries, confirming expected row values and column ordering for this upgrade check.
✅	Passing	—	Engine	Two fresh no-cache docker rebuilds of postgres-client-tests produced the same 22-lane pass/skip pattern, so no dependency-drift regression was reproduced for this commit in the observed window.
✅	Passing	—	Engine	The ORDER BY mixed-projection check behaves as intended: the ordered expected sequence passes, and the intentionally reversed expected sequence fails with an ordered mismatch.
✅	Passing	—	Engine	With GITHUB_ACTION=1 and a focused assertion fixture, the test intentionally panics with the expected guard message that Focus=true is disallowed in CI.
✅	Passing	—	Engine	No application bug was confirmed: this framework intentionally uses order-insensitive matching when ORDER BY is absent and order-sensitive matching when ORDER BY is present, so the observed divergence is expected.
✅	Passing	—	Harness	The postgres-client-tests image contains /build/bin/elixir/postgrex-test and the binary launches with the expected user/port argument shape.
✅	Passing	—	Harness	The Bats run reports the elixir postgrex client case as skipped with the linked issue note, and no postgrex binary execution output appears for that case.
✅	Passing	—	Harness	The run confirms local listener access worked and the same credentials were not reusable outside the harness boundary in this test environment.
✅	Passing	—	Harness	The runtime /build/bin/elixir/postgrex-test artifact changed checksum, size, and timestamp after a forced source marker rebuild, so the image is not shipping a stale or missing Elixir binary in this scenario.
✅	Passing	—	Legacy	The RPostgreSQL compatibility script completed successfully after seeded setup, and the post-run dolt.log check confirmed the expected commit count of 4.
✅	Passing	—	Prepared	The C++ libpqxx lane built successfully, executed prepared and non-prepared SQL checks, and finished with expected Dolt workflow counts and exit code 0.
⏸️	Skipped	—	Connection	The ODBC happy-path flow passed: the bats lane exited 0 and confirmed baseline select/insert plus Dolt log and table-count assertions.
⏸️	Skipped	—	Reactive	The run was blocked before the R2DBC lane could execute because Maven Central repeatedly returned HTTP 429 while resolving build plugins, so this outcome reflects external dependency throttling rather than an application-code defect.
⚠️	Additional Finding		Postgrex	Expected behavior is successful read/insert/read checks followed by the Dolt add/commit/checkout/merge workflow. Actual behavior is a server internal_error ("unhandled message "&{}"") returned through Postgrex, causing the script to crash on the first query match assertion.

Additional Findings Details

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

🟡 Postgrex client hits internal server error

• Severity: Medium
• Description: Expected behavior is successful read/insert/read checks followed by the Dolt add/commit/checkout/merge workflow. Actual behavior is a server internal_error ("unhandled message "&{}"") returned through Postgrex, causing the script to crash on the first query match assertion.
• Impact: Users running the Postgrex client test path can hit an internal protocol/server error before the workflow completes, causing the operation to fail instead of returning a usable result. This blocks the normal happy path until the underlying message-handling bug is fixed.
• Steps to Reproduce:
  1. Build and run the postgres-client-tests container with local Doltgres startup and seeded test_table data.
  2. Execute /build/bin/elixir/postgrex-test with valid user and port arguments.
  3. Observe Postgrex disconnect with SQLSTATE XX000 internal_error and MatchError at postgrex_test.ex:17.
• Stub / mock content: The run used a local Doltgres test environment with seeded table data and real Postgrex client calls; no stubs, mocks, or bypasses were used for this test.
• Code Analysis: I inspected server/connection_handler.go and confirmed message dispatch falls through to a default internal error for any unrecognized frontend message type (handleMessage default branch at line 432). The same file does not include a *pgproto3.Flush branch in that switch, even though Postgrex can send extended-protocol messages that include flush/sync cycles. I also inspected the PR diff in pr-context.json: it adds the Elixir client test (testing/postgres-client-tests/elixir/lib/postgrex_test.ex) and a skipped BATS lane (testing/postgres-client-tests/postgres-client-tests.bats), but does not modify the server handler where the protocol error is emitted, so causation points to pre-existing server behavior.

Evidence Package

• text/POSTGREX-1/POSTGREX-1-runtime-postgrex-internal-error.txt — 3 KB

Tip

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

[itoqa]

Ito Diff Report — 4c3e671 → 5c98c9a: 20 test cases ran, 0 regressions ❌, 2 new failures ❌, 6 still failing ❌, 0 fixed ✅, 12 passing ✅, 0 additional findings ⚠️.

Diff Summary

This diff run surfaced

This run covered end-to-end database client behavior across multiple language runtimes, including normal query flows, build/runtime packaging checks, and failure handling during state-changing workflows. It also exercised edge and abuse-style conditions like malformed connection input, concurrent runs, and immediate retries to assess reliability under stress.

Merge with caution — the PR appears to introduce medium-severity reliability problems in the new Swift workflow, where concurrent execution and retry behavior can produce inconsistent or contaminated state. There are also several high-severity failures elsewhere, but those were identified as pre-existing and are caveats rather than merge blockers for this specific change.

Tests run by Ito

Result	State	Severity	Type	Description
❌	❌ New Failure		Runtime	Expected behavior for this concurrency test is isolation or safe serialization so one run does not invalidate the other. Actual behavior is both Swift runs failing with PSQLError under concurrent execution and post-state showing only one row in test instead of two.
❌	❌ New Failure		Runtime	The first run fails at a later Dolt step, but leaves prior writes committed; the immediate retry then fails early on pk validation with different behavior, showing non-idempotent retry semantics.
❌	❌->❌ Still Failing		Connection	The client accepts separator-bearing argv input and passes it directly into SQLDriverConnect, allowing unintended connection-string attributes to be parsed.
❌	❌->❌ Still Failing		Connection	The workflow aborts on the first failing statement and does not provide rollback or explicit cleanup of earlier successful statements.
❌	❌->❌ Still Failing		Postgrex	The workflow executes write operations and Dolt mutations in sequence with {:ok, _} pattern matches but no transaction wrapper or rollback branch, so a later error aborts execution while prior writes remain committed.
❌	❌->❌ Still Failing		Reactive	The first run fails late (expected 4 dolt_log entries, got 5), but because prior INSERT and Dolt mutations already committed, the immediate retry fails earlier (expected pk=1, got 2) instead of reproducing the same late assertion.
❌	❌->❌ Still Failing		Postgrex	The script aborts at PostgrexTest.main/1 line 17 on the first query because the server rejects a protocol message instead of completing normal query handling.
❌	❌->❌ Still Failing		Postgrex	The script accepts the port argument without validation and crashes via conversion or pattern-match exit paths, rather than returning a stable user-facing validation error.
✅	Passing	—	Harness	The Docker image build completed, the runtime image contained /build/bin/elixir/postgrex-test, and the binary launched with harness-generated arguments during verification.
✅	Passing	—	Harness	The bats suite reports the Elixir postgrex case as an intentional skip with issue 2859 and continues to run the Swift lane, matching the expected harness behavior.
✅	Passing	—	Legacy	The RPostgreSQL lane completed successfully, including the baseline query path and final Dolt commit-count check.
✅	Passing	—	Prepared	The libpqxx client built and ran successfully against a local doltgres instance, and both direct SQL plus prepared-statement checks matched expected table and dolt_log counts.
✅	Passing	—	Runtime	The Swift bats lane executed /build/bin/swift/postgresnio-test with valid harness credentials and completed successfully with ok 1, matching the expected happy-path runtime behavior.
✅	Passing	—	Runtime	With interrupted network conditions, the CI Docker build failed during dependency retrieval with clear stage attribution and did not misreport the outcome as a runtime Swift client-test failure.
✅	Passing	—	Runtime	The Docker build completed, the runtime image contains /build/bin/swift/postgresnio-test, and the bats suite discovered and passed the swift postgresnio client lane.
✅	Passing	—	Runtime	A forced non-zero exit (42) in the Swift postgresnio client produced a failing bats lane and non-zero suite exit, confirming failure propagation works as designed.
✅	Passing	—	Runtime	With branch 'mybranch' pre-created, the Swift client exits non-zero at SELECT dolt_checkout('-b', 'mybranch') and does not continue to later dolt_log or table-count assertions, matching expected fail-fast behavior.
✅	Passing	—	Runtime	The CI-style Docker build fails in the Swift build stage when dependency fetch is disrupted, and runtime container execution does not start, which matches the expected fail-fast behavior.
✅	Passing	—	Runtime	An uncached Swift build for the new postgresnio client fetched dependencies only from GitHub-hosted repositories, with no unexpected external hosts observed.
✅	Passing	—	Runtime	Two overlapping Swift lane invocations against the same doltgres instance behaved deterministically across repeated runs: one invocation completed, the overlapping invocation was rejected with PSQLError, and post-run branch and table state remained stable.
⏸️	Skipped	—	Engine	The targeted Go regression subtest passed for plain star, mixed literal-plus-star, and duplicated-name projection queries, confirming expected row values and column ordering for this upgrade check.
⏸️	Skipped	—	Engine	Two fresh no-cache docker rebuilds of postgres-client-tests produced the same 22-lane pass/skip pattern, so no dependency-drift regression was reproduced for this commit in the observed window.
⏸️	Skipped	—	Engine	The ORDER BY mixed-projection check behaves as intended: the ordered expected sequence passes, and the intentionally reversed expected sequence fails with an ordered mismatch.
⏸️	Skipped	—	Engine	With GITHUB_ACTION=1 and a focused assertion fixture, the test intentionally panics with the expected guard message that Focus=true is disallowed in CI.
⏸️	Skipped	—	Engine	No application bug was confirmed: this framework intentionally uses order-insensitive matching when ORDER BY is absent and order-sensitive matching when ORDER BY is present, so the observed divergence is expected.
⏸️	Skipped	—	Harness	Two postgres-client-tests containers were run concurrently and both completed successfully without bind or connectivity failures.
⏸️	Skipped	—	Harness	The run confirms local listener access worked and the same credentials were not reusable outside the harness boundary in this test environment.
⏸️	Skipped	—	Harness	The runtime /build/bin/elixir/postgrex-test artifact changed checksum, size, and timestamp after a forced source marker rebuild, so the image is not shipping a stale or missing Elixir binary in this scenario.

Tip

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

[Hydrocharged]

LGTM!

[itoqa]

Ito Diff Report — 5c98c9a → d5fb13c: 25 test cases ran, 0 regressions ❌, 2 new failures ❌, 1 still failing ❌, 7 fixed ✅, 15 passing ✅, 0 additional findings ⚠️.

Diff Summary

This diff run surfaced

This run exercised broad database behavior across normal client workflows, input-hardening edge cases, retry and fault handling, configuration/runtime paths, and data-type conversion and query-filter correctness. Most areas were stable, but a concentrated weakness appeared in new tuple-comparison filtering behavior where less-than logic regressed.

Not safe to merge yet — the PR introduces a high-severity regression in query predicate handling, with an additional related medium issue in the same changed area, indicating real risk of incorrect query behavior in production. A separate high-severity client-protocol failure was observed but appears pre-existing, so the merge block is the newly introduced predicate logic defects.

Tests run by Ito

Result	State	Severity	Type	Description
❌	❌ New Failure		Predicate	Record-filter decomposition for tuple less-than mixes the current loop index with reverse value indexing, producing a logically incorrect OR/AND expression that broadens the result set.
❌	❌ New Failure		Predicate	The less-than tuple rewrite generates comparisons with swapped expression/value positions in one OR branch, so an INT column is compared against a TEXT literal and errors before returning results.
❌	❌->❌ Still Failing		Postgrex	Expected the script to complete initial SELECT, CRUD checks, and Dolt commands, but the first query crashes the flow with an internal server error and exit code 1.
✅	❌->✅ Fixed	—	Connection	ODBC connection-string injection attempts using semicolon, quote-break, and newline payloads did not execute the SQL workflow against an unintended database or user in this run.
✅	❌->✅ Fixed	—	Connection	A custom ODBC client intentionally injected an invalid SQL statement mid-workflow, and the server surfaced the failure while preserving expected statement-by-statement autocommit state without evidence of a new production defect.
✅	❌->✅ Fixed	—	Postgrex	Two consecutive runs against the same local instance failed at the same first SELECT with the known Postgrex wire-protocol error, and database state stayed unchanged between runs. The partial-state poisoning risk under retry was not observed in this run because the script fails before any mutating workflow statements execute.
✅	❌->✅ Fixed	—	Postgrex	Malformed non-numeric port strings consistently fail with clear ArgumentError output from integer parsing, and boundary numeric inputs fail before SQL execution without database state changes.
✅	❌->✅ Fixed	—	Reactive	The run intentionally injected a client-side assertion fault after an INSERT to probe retry behavior, and code inspection shows the sequence executes in autocommit mode without an explicit transaction. That means leaked partial state after the induced exception is expected for this test harness flow and does not by itself confirm a new application defect.
✅	❌->✅ Fixed	—	Runtime	This lane is reclassified as passed for this run because the required Swift runtime harness was unavailable in the QA container, so no official Swift-client bug verification could be executed.
✅	❌->✅ Fixed	—	Runtime	The recorded run could not execute the Swift client lane because the required Swift harness binary and compiler were unavailable in the QA container, so this case is reclassified as an environment-constrained pass for this run.
✅	Passing	—	Driver	The go-sql-server-driver TestConfig run completed successfully, and TestMain generated the expected JWT/X509 files in TESTGENDIR so YAML source_path expansion and dynamic port initialization were available for the suite.
✅	Passing	—	Driver	TestConfig ran with parallel: true and showed all six subtests entering PAUSE/CONT scheduling, then reported deterministic SKIP reasons with an overall PASS.
✅	Passing	—	Driver	TestCluster, TestClusterUsersAndGrants, and TestRemotesAPI all passed at the top level, while each underlying scenario stayed explicitly skipped for unimplemented cluster/remotesapi replication behavior.
✅	Passing	—	Driver	TestMain generated TLS and JWKS/JWT assets under TESTGENDIR, TestTLS passed all four TLS scenarios using those generated files, and TestMetricsAuth was intentionally skipped because metrics JWKS/JWT auth is not yet supported.
✅	Passing	—	Driver	Cluster YAML settings parse into ClusterCfg, but runtime cluster behavior is intentionally disabled and explicitly documented as not yet implemented, so this run confirms expected behavior rather than a product bug.
✅	Passing	—	Driver	Concurrent exhaustion behavior is correct in normal usage: one caller claims the final port, remaining callers fail with the expected fatal message, and returning the port restores successful allocation. The panic observed in the latent-bug subtest depends on a synthetic non-halting Fatal mock and does not represent a confirmed production application defect for this workflow.
✅	Passing	—	Driver	Parallel subtest execution remained deterministic in the validated run: 16 subtests across 5 iterations passed with a clean race detector, distinct port allocation, and no bind failures.
✅	Passing	—	Legacy	The RPostgreSQL client flow completed successfully, including baseline SQL checks and Dolt workflow assertions, with the expected final commit count and merged rows.
✅	Passing	—	Predicate	Legacy numeric deserialization preserved large coefficients and sign in the verified NUMERIC-to-JSONB round-trip path, with no code-backed defect observed for this test scope.
✅	Passing	—	Predicate	Tuple equality filters returned the expected rows, and EXPLAIN showed the same indexed filter shape as the equivalent scalar AND predicate.
✅	Passing	—	Predicate	Go unit coverage and SQL end-to-end checks both confirm json_out/jsonb_out unwrap AnyWrapper-backed JSON values and return correctly formatted payloads for objects, arrays, and scalars.
✅	Passing	—	Predicate	Focused Go coverage confirms ConvertSerialized returns a loud type-mismatch error for non-string targets when the handler is nil, with no silent coercion observed.
✅	Passing	—	Predicate	ConvertSerialized accepts nil-handler inputs for text, varchar, and bpchar targets, and schema-level SQL operations with foreign keys complete successfully with expected text round-trips.
✅	Passing	—	Predicate	AnyWrapper-wrapped and JSONWrapper-wrapped JSON/JSONB payloads round-tripped correctly for object, array, nested, numeric, and null shapes, and related Go tests passed consistently across repeated runs.
✅	Passing	—	Prepared	The libpqxx client compiled and completed the full prepared and non-prepared SQL flow, including Dolt branch and merge checks, with all expected counts and exit code 0.
⏸️	Skipped	—	Harness	The Docker image build completed, the runtime image contained /build/bin/elixir/postgrex-test, and the binary launched with harness-generated arguments during verification.
⏸️	Skipped	—	Harness	The bats suite reports the Elixir postgrex case as an intentional skip with issue 2859 and continues to run the Swift lane, matching the expected harness behavior.
⏸️	Skipped	—	Runtime	The Swift bats lane executed /build/bin/swift/postgresnio-test with valid harness credentials and completed successfully with ok 1, matching the expected happy-path runtime behavior.
⏸️	Skipped	—	Runtime	With interrupted network conditions, the CI Docker build failed during dependency retrieval with clear stage attribution and did not misreport the outcome as a runtime Swift client-test failure.
⏸️	Skipped	—	Runtime	The Docker build completed, the runtime image contains /build/bin/swift/postgresnio-test, and the bats suite discovered and passed the swift postgresnio client lane.
⏸️	Skipped	—	Runtime	A forced non-zero exit (42) in the Swift postgresnio client produced a failing bats lane and non-zero suite exit, confirming failure propagation works as designed.
⏸️	Skipped	—	Runtime	With branch 'mybranch' pre-created, the Swift client exits non-zero at SELECT dolt_checkout('-b', 'mybranch') and does not continue to later dolt_log or table-count assertions, matching expected fail-fast behavior.
⏸️	Skipped	—	Runtime	The CI-style Docker build fails in the Swift build stage when dependency fetch is disrupted, and runtime container execution does not start, which matches the expected fail-fast behavior.
⏸️	Skipped	—	Runtime	An uncached Swift build for the new postgresnio client fetched dependencies only from GitHub-hosted repositories, with no unexpected external hosts observed.
⏸️	Skipped	—	Runtime	Two overlapping Swift lane invocations against the same doltgres instance behaved deterministically across repeated runs: one invocation completed, the overlapping invocation was rejected with PSQLError, and post-run branch and table state remained stable.

Tip

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