You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently logging with assertions only indicates the task name failing. In the case of composite operations this makes it quite hard to identify which query actually failed the assertion.
I think this is small change on the Asserting Runner e.g.
async def __call__(self, *args):
params = args[1]
return_value = await self.delegate(*args)
if AssertingRunner.assertions_enabled and "assertions" in params:
if isinstance(return_value, dict):
for assertion in params["assertions"]:
try:
self.check_assertion(assertion, return_value)
except exceptions.RallyTaskAssertionError as e:
self.logger.info(f"Assertion failed on: {[params.get('name')]}")
raise e
else:
self.logger.debug("Skipping assertion check as [%s] does not return a dict.", repr(self.delegate))
return return_value
The AssertingRunner has no visibility of the child runner and we dont have any guarantee of the params in args. The name should exist however and would be sufficient if the user names their searches uniquely within a composite - which should be good practice.
The text was updated successfully, but these errors were encountered:
With this commit we attempt to extract an operation's `name` property
and if present, we include it in the assertion message. This is mostly
useful for operations inside a composite, as we lack context there and
the error message only indicates an error "somewhere" in the composite
but not exactly in which specific operation. With this commit, it is
possible to get that information.
Closeselastic#1196
With this commit we attempt to extract an operation's `name` property
and if present, we include it in the assertion message. This is mostly
useful for operations inside a composite, as we lack context there and
the error message only indicates an error "somewhere" in the composite
but not exactly in which specific operation. With this commit, it is
possible to get that information.
Closes#1196
Currently logging with assertions only indicates the task name failing. In the case of composite operations this makes it quite hard to identify which query actually failed the assertion.
I think this is small change on the Asserting Runner e.g.
The AssertingRunner has no visibility of the child runner and we dont have any guarantee of the params in args. The name should exist however and would be sufficient if the user names their searches uniquely within a composite - which should be good practice.
The text was updated successfully, but these errors were encountered: