Fix connection secure port management. - #162
Conversation
|
@baconfield . @nils-borrmann-tacto , @long2ice , damn, this PR should go first because the failed CI in the dev - https://github.com/long2ice/asynch/actions/runs/27552079391/job/81440866403 . @barakor, @dmkulazhenko , @DaniilAnichin , @pohmelie, please help with reviews. |
|
Seems to be ok; about the pytest-asyncio: mostly I've dealt with it by switching to anyio, but I don't think this is a PR to do it in. |
Yeah, you are right, this PR is not about |
barakor
left a comment
There was a problem hiding this comment.
Seems ok overall, but the change in asynch/connection.py that I commented about is problematic
Co-authored-by: Barak <26878518+barakor@users.noreply.github.com>
Co-authored-by: Barak <26878518+barakor@users.noreply.github.com>
Resolved with #163 |
The changes from the #163 were here before - https://github.com/long2ice/asynch/pull/162/changes#diff-94026d54d9ecff66c0362322fe026b6995eb0bdbb56bb8bf84447fc7fa148b04 . You can close the #163 PR. |
|
@DaniilAnichin , @pohmelie , hello. In spite of these changes, could you re-review and re-approve them in case they are really OK? After that this PR can go to the final-boss review. Sorry for these bureaucratic troubles. |
|
@long2ice , hello. This PR is ready to be merged. |
…dling, PEP 249 - #162 (@stankudrow): a secure connection without an explicit port went to 9000 instead of 9440. Reworked rather than ported: the original patch resolved the port before reading `secure` out of the DSN, so `clickhouses://host/db` - its own motivating case - still got 9000, and it regressed bare `Connection()` by passing None for every unset field. Here the port simply stays None until the proto layer resolves it from the scheme, and the facade reads the effective port back. - #150 (@nils-borrmann-tacto): a rejected query disconnected the connection, so every SQL error cost a pooled connection. Server exceptions now leave it open (the exception packet leaves the stream at a packet boundary), with `is_query_executing` cleared so the next query is accepted. Deviation from the original: a failed query no longer updates the tracked database - the patch as proposed let a failed `USE db` move the client's idea of it. - #146 (@vizor-games): None in a non-Nullable column surfaced as whatever primitive failed first. Placed in the slow path of `prepare_items` (which already iterates) plus a translation at the dispatcher for columns that bypass it, rather than the proposed `None in items` scan on every column: that would have taxed the fast path and, running before `prepare_items`, would have broken `input_format_null_as_default`. - #159 (@turquoisehealth): took the additive part of the PEP 249 work - module globals, `connect()`, exception re-exports, `Cursor.arraysize`. Left out the behaviour changes (`commit()` as a no-op, `description` returning type objects) and the pool cross-loop reset, which leaks connections and reads private asyncio attributes. threadsafety is 1, not the 2 the PR proposed: connections own a socket and a parse buffer and are not shareable between threads.
|
Thanks — the bug is real and is fixed on
The fix on I left the parameter-vs-DSN precedence inversion and the |
Fix errors in the connection security parameter + minor (un)related corrections
This PR was inspired by #138, and I thought it would be a good idea to split the secure connection case and query parametrisation, focusing only on the first part. It wasn't straightforward, but perhaps that's for the best.
@barakor, I hope I'm not stepping on your toes — I fully acknowledge your contribution. I'd appreciate it if you could also review this PR; your suggestions will be greatly appreciated and carefully addressed.
Some tests used to fail due to issues with parameter substitution processing (related to #147). @baconfield, @dmkulazhenko, could you please review these changes?
I experimented with configuring connections in the tests, which caused tests using a bare
Connection()orPool(...)withoutconnection_kwargsto fail. This is actually a positive outcome, as it revealed the fragility of those tests.@long2ice, @nils-borrmann-tacto, @DaniilAnichin, I had some difficulty specifying the pytest-asyncio
asyncio_default_fixture_loop_scopeattribute and addressing the warning from pytest: neither the "session" nor the "function" scope resolves the issue. By the way, your reviews would be very welcome.