GeezerVison

🟠 High — This branch now injects cloudfetch_enabled="false" into session_conf, but the declared floor is still ^1.4.0, and the PR says released 1.4.0 doesn't consume this key locally. On a 1.4.0 wheel the key goes straight to the server as a session parameter. The comment this PR removes said the SEA endpoint "enforces its own allow-list and rejects unknown keys". So use_kernel=True, use_cloud_fetch=False used to connect (cloud fetch was just ignored) and may now fail at open_session for anyone the resolver puts on 1.4.0.

The PR description already calls this a merge gate. Please don't merge until the floor in pyproject.toml/poetry.lock is bumped to the first native release containing kernel#436. If that can't land together with this change, gate the injection on a capability check, as the other kernel options do.

(Anchored to the nearest changed line — see the description for the exact location.)

Acknowledged; this is the same native-release gate tracked in the current dependency thread. This PR must remain unmerged until the native release containing kernel #436 is published and both pyproject.toml and poetry.lock require it. The release version is not assigned yet. Leaving this thread open until those dependency updates are present.

Thanks for confirming. The code at line 398 still adds cloudfetch_enabled="false" without any check, and the declared floor is still ^1.4.0, so the 1.4.0 regression is still possible. Leaving this thread open as the merge gate. It's resolved once pyproject.toml and poetry.lock require the native release that contains kernel#436. If that release slips, a capability check around the injection would also resolve it.

🟡 Medium — cloudfetch_enabled only works as a client-side setting in a kernel build that includes databricks-sql-kernel#436. pyproject.toml:73 still allows ^1.4.0. Per the comment this PR deleted, a 1.4.0 binary forwards session_conf unchanged to the SEA endpoint, which rejects unknown keys. So on the wheel that resolves today, use_cloud_fetch=False would go from "ignored" to either failing at open_session or being silently ignored by the server. The PR description already lists this as a merge gate. Please make sure this PR includes the floor bump (and the poetry.lock refresh) before merge, so the gate lives in dependency metadata and not only in CONNECTION_PARAMETERS.md prose.

Acknowledged; this is the same native-release gate tracked in the current dependency thread. This PR must remain unmerged until the native release containing kernel #436 is published and both pyproject.toml and poetry.lock require it. The release version is not assigned yet. Leaving this thread open until those dependency updates are present.

Thanks for confirming. Your plan to keep this unmerged until the native release with kernel #436 ships, and until both pyproject.toml and poetry.lock require that version, is the right gate. No dependency bump is visible yet: pyproject.toml still allows ^1.4.0, and the code at line 399 still sends cloudfetch_enabled unconditionally when use_cloud_fetch=False. So this thread stays open as the blocking item until the floor bump and the lock refresh land.

🟡 Medium — The fix only works with databricks-sql-kernel #436 (large-result delivery with CloudFetch off), but only KERNEL_REV is bumped. pyproject.toml / poetry.lock still allow older wheels. If the resolver picks one of those, use_cloud_fetch=False now sends cloudfetch_enabled=false to a kernel that can't deliver large results without CloudFetch. Large results would then break or come back incomplete, even though the CHANGELOG and CONNECTION_PARAMETERS.md now list the option as supported (✅). Please make the floor bump part of this PR, or block the merge on it, so the docs and the dependency graph match. Otherwise, document that the option needs kernel ≥ the release containing #436.

Acknowledged; this is the same native-release gate tracked in the current dependency thread. This PR must remain unmerged until the native release containing kernel #436 is published and both pyproject.toml and poetry.lock require it. The release version is not assigned yet. Leaving this thread open until those dependency updates are present.

Thanks for confirming. Agreed: the right fix is to keep this PR unmerged until the native release containing kernel #436 ships and both pyproject.toml and poetry.lock require that version. Right now the dependency graph still allows older wheels, and the docs and CHANGELOG already mark use_cloud_fetch=False as supported. I'm leaving this thread open until the floor bump is in the diff so it stays in the unresolved queue as a merge blocker.

🟠 High — This branch now sends cloudfetch_enabled="false" whenever a caller passes use_cloud_fetch=False. The PR says the kernel only delivers large results correctly with CloudFetch disabled after databricks-sql-kernel#436. But pyproject.toml:73 still allows ^1.4.0, and only KERNEL_REV (used for source builds) points at the fix.

On any wheel in the allowed range, users who already set use_cloud_fetch=False (it was silently ignored before, so results came back fine via CloudFetch) would now get the broken disabled-CloudFetch behavior on large results. On a wheel that doesn't consume the key locally, it would instead be forwarded to the server as an unknown session conf. Either way, existing working setups regress.

The PR description already lists the pin bump as a pre-merge step. Please make it a hard gate: bump the floor in pyproject.toml / poetry.lock in this PR, or hold the merge, so the resolver can't pick a kernel without the fix.

Confirmed: this PR remains merge-gated until the native package containing kernel #436 is published and both pyproject.toml and poetry.lock require that release. The release version is still unassigned. The PR description retains this prerequisite, and the documentation cleanup leaves that gate in place.

Thanks for confirming the merge gate. The code hasn't changed yet, though: pyproject.toml and poetry.lock still allow kernel wheels without #436, so the regression risk is still there. I'll leave this thread open as the gate. It can be resolved once the PR bumps the floor in both files to the release that includes #436.