the event request_success should pass request and response to the listener

[tobeczm]

Is your feature request related to a problem? Please describe.

I want to fetch the headers of request or response when a request is successful.

Describe the solution you'd like

@events.request_success.add_listener
def my_success_handler(request_type, name, response_time, response_length, request, response, **kw):
    print("Successfully made a request to: %s" % name)

Describe alternatives you've considered

Additional context

[heyman]

That wouldn't work when using Locust to load test non-HTTP stuff. I'd recommend to either create a custom client, or wrap the client calls instead.

[tobeczm]

That wouldn't work when using Locust to load test non-HTTP stuff. I'd recommend to either create a custom client, or wrap the client calls instead.

At least, we could put them into the optional arguments:

@events.request_success.add_listener
def my_success_handler(request_type, name, response_time, response_length, **kw):
    if 'request' in kw: 
        print('request:', kw['request'])
    if 'response' in kw: 
        print('response:', kw['response'])
    print("Successfully made a request to: %s" % name)

[heyman]

At least, we could put them into the optional arguments:

That's a possibility. The only issue I see with that is that people would start relying on their existence and all of a sudden we've crippled support for non-HTTP stuff in practice. Not sure if it would be worth it - maybe?

[felix-hubert-eai]

Was also looking for a way to access the request and response in the listener. Any chances this will be possible?

On a similar idea, is it possible to access the runner inside a listener? I'm interested in having access to the current user_count inside a request_success hook.

[heyman]

On a similar idea, is it possible to access the runner inside a listener? I'm interested in having access to the current user_count inside a request_success hook.

The runner is available through the Environment instance, and you can grab a reference to it from the init event:

from locust import events

@events.init.add_listener
def _(environment, **kwargs):
    @events.request_success.add_listener
    def _(**kw):
        print("Current user count:", environment.runner.user_count)

[ludeknovy]

Hi, I support this idea as well, it would be very handy to have request/response at disposal. I would like to be able to access status code for enhanced reporting from listener. Do we have any final decision on this already?

[cyberw]

I like the idea and will happily merge it, but someone else needs to write the code and some test cases :)

[ludeknovy]

@cyberw btw is it actually a good idea to pass whole request and response from the performance perspective?

My use case could be easily covered by adding hostname and status_code for now:

self.environment.events.request_success.fire(
                    request_type=request_meta["method"],
                    name=request_meta["name"],
                    response_time=request_meta["response_time"],
                    response_length=request_meta["content_size"],
                    request_hostname=request_meta["hostname"],
                    response_status_code=response.status_code
                )

[cyberw]

(ignore my first, now deleted, response. I was on mobile and confused on which ticket this was)

Passing the response body as a string (which might not otherwise even be read into Python unless the user asks for it) would be a big no-no for performance, but passing the response object (same as we are passing to the with block when catch_response=True) shouldnt be too bad. If we can get the request object as well that would be great.

I’d also like to pass the User object.

Tbh, I’m not super worried about other protocols not suppling these values, but we should definitely mention it in our ”new client”-example in the docs.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[cyberw]

Fixed in 1.5.0 #1750 (except for the request)