Skip to content
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

Default implementation of on_request_success and _failure lacks **kwargs declaration #745

Closed
karol-brejna-i opened this issue Mar 7, 2018 · 0 comments

Comments

@karol-brejna-i
Copy link
Contributor

karol-brejna-i commented Mar 7, 2018

Description of issue / feature request

When implementing new (custom) client or trying to inject more metadata into results the user will usually need to introduce dedicated success/failure handlers that may extend the default list of parameters and/or fire success/failure events manually (probably with additional arguments).

Take this for example:
https://gist.github.com/karol-brejna-i/da6295a4d7bf25c2796fa95c622e7d80

Expected behavior

Users should be able to introduce additional request handlers that include extended parameter lists.

Actual behavior

Because of the way the default request handlers are implemented (

def on_request_success(request_type, name, response_time, response_length):
), Locust will fail in this case with something similar to:
https://gist.github.com/karol-brejna-i/4ab6b0a283a5cc56e4013acef31622f8

Environment settings (for bug reports)

  • OS: doesn't affect the results; Docker, tested on Ubuntu 16.04, Windows 10
  • Python version: 3.6
  • Locust version: 0.8.1

Steps to reproduce (for bug reports)

Define additional handlers, fire request_success with additional arguments as described in https://medium.com/p/183d2ae4a4c2

Suggested solution

Making the implementation adhere to the following advice (https://docs.locust.io/en/latest/extending-locust.html):

It’s highly recommended that you add a wildcard keyword argument in your listeners (the **kw in the code above), to prevent your code from breaking if new arguments are added in a future version.

would solve the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant