wait with stop_on_nohandler=True does not raise exceptions on unexpected reqs after expected ones

[akursar]

If I don't set up any expected requests, making a request inside a wait(raise_assertions=True, stop_on_nohandler=True) will raise the expected AssertionError:

with httpserver.wait(raise_assertions=True, stop_on_nohandler=True, timeout=5):
    requests.get(httpserver.url_for("/1"))

AssertionError: No handler found for request

However, if I configure one or more (ordered) requests, and then send more reqs than expected, no such AssertionError is raised:

httpserver.expect_ordered_request("/1", method="GET").respond_with_data(status=204)
httpserver.expect_ordered_request("/2", method="GET").respond_with_data(status=204)
with httpserver.wait(raise_assertions=True, stop_on_nohandler=True, timeout=5):
    requests.get(httpserver.url_for("/1"))
    requests.get(httpserver.url_for("/2"))
    # Unexpected request - I think this should cause the wait to fail, but no exception is raised
    requests.get(httpserver.url_for("/3"))

I expect the unexpected /3 request to trigger the context manager to raise an AssertionError as there is no configured handler for /3. I do see in the httpserver.log that the server received the third request and returned 500, but no exception is raised. I'm not sure if this is a bug, or maybe I'm misinterpreting how/when stop_on_nohandler works?

[csernazs]

Hi @akursar ,

This seems to be a valid issue, however if I take the docstrings seriously then this changes the purpose of wait().

It says:

Context manager to wait until the first of following event occurs: all ordered and oneshot handlers were executed, unexpected request was received (if stop_on_nohandler is set to True), or time was out

So it waits for the first of the following events:

1. all ordered and oneshot handlers were executed, or
2. unexpected request was received (if stop_on_nohandler is set to True)
3. or time was out

So in your reproducer, the 1st option gets satisfied (all ordered and oneshot handlers were executed), and then since it waits for the "first" such event, it sets the result to success and does not wait for other events.

Then you issue the extra request, which would trigger the 2nd step but hence the 1st already triggered it does not affect the end result. This means that the code works as described in the docstrings, I think.

Here is the code:

pytest-httpserver/pytest_httpserver/httpserver.py

Lines 1445 to 1447 in 043190d

	)
	if self._waiting_settings.raise_assertions and not waiting.result:
	self.check_assertions()

In line number 1446, it does not get to check_assertions() as the waiting.result is already set to True due to the "all ordered and oneshot handlers were executed" rule.

In order to make it working as you expected, the docstring, and thereby the behavior, would need to be changed. So it would be a breaking change. It would not be sufficient to check the first case but to wait till the end.

Zsolt

[csernazs]

I think, for your case, you would need something like this:

def test_issue(httpserver: HTTPServer):
    httpserver.expect_ordered_request("/1", method="GET").respond_with_data(status=204)
    httpserver.expect_ordered_request("/2", method="GET").respond_with_data(status=204)

    with httpserver.with_check():
        requests.get(httpserver.url_for("/1"))
        requests.get(httpserver.url_for("/2"))
        # Unexpected request
        requests.get(httpserver.url_for("/3"))

Implementation in HTTPServer:

    @contextmanager
    def with_check(self):
        yield self
        self.check()

So this would simply call check at __exit__.
It would have no waiting logic like in wait().

What do you think?

Zsolt