-
Notifications
You must be signed in to change notification settings - Fork 7
tests: Add timeout to ip_block derective
#925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
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
1ca32f9 to
c4eebc4
Compare
768660b to
59cc826
Compare
RomanBelozerov
requested changes
Dec 22, 2025
RomanBelozerov
requested changes
Dec 23, 2025
3c873c4 to
f25b955
Compare
RomanBelozerov
approved these changes
Jan 14, 2026
f25b955 to
5cd7a3a
Compare
Before this patch deproxy_client coldn't establish connection without sending request. `connect()` called from `start()` method is async and finishing of connection establising must be done in `handle_write()`. Connection is established only if socket is ready to write. But in previous version we couldn't reach `handle_write()` handler because `writable()` always returned `False`, due zero number of pending request at connection stage. To fix this we introduced two the new versions of `writable()` and `handle_write()` those used when connection is not established and changed to another two when connection established.
Add frang ip_block time range tests: - Add tests to verify new behaviour of `ip_block <senconds>`, now `ip_block` not permanent and block duration time can be specified to `ip_block`. To have permanent block use `ip_block 0`. Add frang ip_block configuration tests and fix blinking tests: - Add tests to verify `ip_block <seconds>` configuring correctly. - Add `wait_for_connection_open()` to guarantee connection establishing order in `FrangIpBlockConn` tests.
We should wait while all connection will be closed, before trying again
We must not set `server_hostname` when client started, at this moment connection already established
We must not set STOPPED state manually, use `stop()` method when it needs. Otherwise it breaks stopping logic that leads to corrupted internal state of the client on subsequent uses use of the client. Example: 1. Call client.start() 2. Call client.send_request() 3. HTTP error occured, client disconnected handle_close() called state set to STOPPED. 4. Call client.restart() # dosn't take effect, already in STOPPED state. 6. Call client.send_request() # Error client internal counters are broken.
In the test_h2_field_validity.py we doing `start_all_services()` in `subtest` it means we also need to do stop, to gracefully shutdown client. Otherwise at the next iteration of subtest client will be in `STARTED` state with active network connection and internal state from previous iteration.
It doesn't make sense to wait 60 seconds on tcp segmentation for this test. We send very few segments in this test thus high network latency is not expected.
- Get rid of _do_close - Add assertion for connection opening
Add small comment
5cd7a3a to
4382386
Compare
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.
No description provided.