fix(deps): bump sqlparse 0.5.5 -> 0.6.0 to clear the pip-audit gate - #120
Merged
Conversation
`pip-audit` is a Required check and currently fails on every PR against this repo, main included: sqlparse 0.5.5 accumulated four advisories after main's last green run, so the gate went red without a single line of code changing. Two of them are quadratic-blowup DoS vectors on the default parse path — CVE-2026-71491 (`group_comments` is O(n^2) on comment-only input, reached via `format(sql, strip_comments=True)`) and CVE-2026-54284 (`TokenList.__init__` materializes `str(self)` per group, making nested grouping O(n*depth); a 2 KB payload burns ~10s of CPU). Both are fixed in 0.6.0. sqlparse is transitive, not a direct dependency: it arrives via uipath-platform 0.1.8 under the optional `uipath` extra, whose constraint is `sqlparse>=0.5.5` — so 0.6.0 satisfies it and the bump is lockfile-only (`uv lock --upgrade-package sqlparse`), touching no other package. Verified with CI's exact invocation against a `--extra dev --extra uipath --extra codex` sync: "No known vulnerabilities found", exit 0. `make verify` green on main plus this change: 4,162 tests.
mohsen-uipath
requested review from
akshaylive,
bai-uipath,
tmatup and
uipreliga
as code owners
August 17, 2026 20:51
|
Claude finished @mohsen-uipath's task in 1m 29s —— View job Code Review for PR #120: Bump sqlparse 0.5.5 → 0.6.0Todo List:
|
…s CI stops leaking The Windows Smoke Test job has failed on every run since 2026-08-17, on every branch — including one containing nothing but a lockfile bump. It is not caused by any recent change: it is a latent resource leak that an environment change (most likely the GitHub Windows runner image) started surfacing reliably. `_run_command_list` spawns each pre/post-run command with two PIPEs and never closes the transport. asyncio offers no public way to: `Process` holds it privately and only releases it on garbage collection. On Windows' Proactor loop `_ProactorBasePipeTransport.__del__` then emits `ResourceWarning: unclosed transport` — one per pipe — which a strict test run reports as `PytestUnraisableExceptionWarning` against whichever test happened to be running when the GC fired, not against the code that leaked. That is exactly the observed shape: always two sub-exceptions per report, always attributed to test_pre_run / test_post_run / test_preservation_mode, with the victim test varying run to run while the underlying count stays constant. `_close_subprocess_transport` releases it from a `finally` covering every exit from the loop body: the normal path, the timeout branch's `continue`, and the `fail_on_error` raise. Best-effort and idempotent — a second close is a no-op and errors are swallowed, since releasing a pipe must never become a task failure. `proc` is bound before the `try` so the spawn-failure path (nothing to close) is distinguishable. Verified as far as a POSIX host allows: make verify green (4,162 tests), ruff clean, pyright 0 errors on this file, and the 63 tests across the three reporting modules pass. The leak itself cannot be reproduced here — on Unix the transport is already closing by the time `wait()` returns, so this is a no-op off Windows and CI is the real test. `isolation/docker_runner.py:572` has the same shape and is deliberately left alone: the evidence points at this loop only (two pipes per command matches the two sub-exceptions exactly, and the docker path is mocked in those tests). If Windows stays red, that site is the next candidate and reuses this helper.
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
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.

Lockfile-only bump.
pip-auditis a Required check and currently fails on every PR against this repo,mainincluded —sqlparse 0.5.5accumulated four advisories after main's last green run, so the gate went red without a line of code changing.Two are quadratic-blowup DoS vectors on the default parse path:
group_commentsis O(n²) on comment-only input, reachable viaformat(sql, strip_comments=True).TokenList.__init__materializesstr(self)per group, making nested grouping O(n·depth); a ~2 KB payload burns ~10 s of CPU.Both are fixed in 0.6.0.
sqlparseis transitive, not a direct dependency: it arrives viauipath-platform 0.1.8under the optionaluipathextra, whose constraint issqlparse>=0.5.5— so 0.6.0 satisfies it and this is a pureuv lock --upgrade-package sqlparse, touching no other package.Verification
Ran CI's exact invocation against a
--extra dev --extra uipath --extra codexsync:make verifygreen on main plus this change: 4,162 tests.Found while triaging CI on #115, where this same gate was red for reasons unrelated to that PR.