snowflake-connector-python: Add versions 4.7.3, 4.7.4 - #2048
Merged
luhenry merged 5 commits intoSep 20, 2026
Merged
Conversation
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The wiremock patch is rebased: upstream replaced the start retry count with a timeout in seconds, so the 120s budget is set on that instead.
The bare `include:` python list shared no key with the `version` matrix axis, so each entry merged into every combination in order and the last one (cp314t) silently overwrote matrix.python for every leg -- only cp314t ever built, for every version, since the version-axis refactor (#1937). Restore a real `python:` axis alongside it. That surfaced the actual cp314t (and now cp312/cp313/cp314) failure: test_auth_keypair_ecdsa_unsupported_curve generates a SECP192R1 key as test setup, and our riscv64 cryptography wheel's OpenSSL build has no legacy provider, so cryptography itself raises UnsupportedAlgorithm before the connector's own curve check ever runs. Deselect it.
Contributor
Author
|
…eshold Build 4.7.4 cp312 failed: test_get_application_path_is_fast_on_deep_call_stacks asserts the average wall-clock time of get_application_path() at a 150-frame-deep call stack stays under a hardcoded 1.0ms, guarding against a regression to an inspect.stack()-based implementation that reads every frame's source file (GH-2908 / SNOW-3691001). On this repo's shared riscv64 runners the same, non-regressed frame-walking implementation averaged 2.286ms in the failing job's log, 2.3x the threshold -- plain per-instruction cost on this architecture plus load from other concurrent matrix jobs on the same shared runner pool, not a code regression. The upstream test file is byte-identical between the 4.7.3 and 4.7.4 tags, so the same patch (0004, raising the ceiling to 10ms, well above the one observed sample) applies to both pending versions. Build 4.7.3 cp313 and Build 4.7.4 cp314 also failed on this run, but their job logs are unavailable everywhere I checked (GitHub API, raw blob storage, and the full run-log zip all 404/omit them), and get_workflow_job shows their "Build wheels" step stuck at status=in_progress with every later step left pending -- unlike Build 4.7.4 cp312's clean pytest failure and full log. That signature, plus both runs finishing in ~10-11.5 minutes against 17-30 minutes for every successful leg, points to a riscv64 runner crash/disconnect rather than a code-level failure. I triggered a safe rerun_failed_jobs (no force-push) to get fresh logs for those two, but the runner pool stayed queued for over an hour with no job starting, so this could not be confirmed. No fix is applied for those two failures; they likely just need CI to retry once the runner pool clears. Upstream-Status: Inappropriate [riscv64 runner is slower per-instruction than upstream's CI hosts, and shared with concurrent matrix jobs; the 1ms threshold assumes faster/dedicated hardware]
test_file_is_not_updated (test/unit/test_cache.py) writes the cache file three times and asserts os.path.getmtime() strictly advances after each write. Before the second write-then-assert-greater pair the test already sleeps 0.1s to guarantee the filesystem's mtime clock ticks forward between writes, but the third pair (triggered by advancing the mocked snowflake.connector.cache.now() past entry_lifetime) has no such sleep, even though that write still hits the real filesystem clock, not the mocked one. On this repo's riscv64 runners the two real-wall-clock writes landed within the same mtime tick, failing the final `os.path.getmtime(tmp_cache_file) > second_updated_time` assertion with equal values (run 35440238662, job "Build snowflake-connector-python 4.7.4 cp313-manylinux_riscv64"). Confirmed against real upstream sources: the test file is byte-identical between the v4.7.3 and v4.7.4 tags, and the missing sleep is an asymmetry within the test itself (the same 0.1s sleep already exists two lines earlier for the same purpose), not a functional defect in cache.py. Only the 4.7.4 cp313 leg hit the race this run — all four 4.7.3 legs happened to land on different mtime ticks — but since both versions carry the identical unpatched test, both get the fix. Add a 0005 patch to both patches/snowflake-connector-python/4.7.3/ and patches/snowflake-connector-python/4.7.4/, matching the sleep already used earlier in the same test. Validated with `git apply --check` against fresh clones of the v4.7.3 and v4.7.4 tags, individually and as the full 0001-0005 stack.
luhenry
force-pushed
the
github-actions/nightly-upgrade/snowflake-connector-python
branch
from
September 19, 2026 18:29
48038cc to
e80d813
Compare
luhenry
marked this pull request as ready for review
September 20, 2026 07:10
luhenry
deleted the
github-actions/nightly-upgrade/snowflake-connector-python
branch
September 20, 2026 07:10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automatically generated by the nightly
check_versions.pyrun.snowflake-connector-python v4.7.2 -> v4.7.3, v4.7.4
Every
- version:entry added todocs/packages/snowflake-connector-python.yamlis built by this PR's ownbuild-snowflake-connector-python.ymlrun; merging publishes the wheels.