Conversation
* set loglevel correctly * gitignore --------- Co-authored-by: Marvin Klerx <marvin.klerx@imbus.de>
* v1 keywordretrylistener * v1 keywordretrylistener * retry kewords if failed * set loglevel for keyword retry * docs * docs * tests * removed status param * removed not required imports --------- Co-authored-by: Marvin Klerx <marvin.klerx@imbus.de>
|
@Snooz82 : PR contains keyword retry listener |
|
I did some refactoring, that you should merge into your branch. This includes:
Please also see the comments in your code. |
src/RetryFailed/retry_failed.py
Outdated
| registered_retry_keyword.kw_lineno == kw_data.kw_lineno | ||
| ): | ||
| return | ||
| self.retry_keywords.append(kw_data) |
There was a problem hiding this comment.
this whole start_keyword basically does add a keyword to the list of keyword that can be retried.
Couldn't that just be done in the end_keyword?
src/RetryFailed/retry_failed.py
Outdated
| if self._original_log_level: | ||
| BuiltIn().set_log_level(self._original_log_level) |
There was a problem hiding this comment.
shouldn't the log level only be decreased by the keyword that did increase it?
e.g. if a userkeyword has to be retried, all its called keywords should be executed on the elevated log level. This here seems to switch back to the original, after the first library keyword.
There was a problem hiding this comment.
added code to reset log level only on failed / passed state by the keyword which has initially changed the log level
src/RetryFailed/retry_failed.py
Outdated
| match_kw_retry = False | ||
| kw_to_retry: KeywordMetaData | ||
| for index, kw in enumerate(self.retry_keywords): | ||
| if kw.kw_name != executed_kw_name or kw.kw_source != executed_kw_source: | ||
| continue | ||
| else: | ||
| match_kw_retry = True | ||
| current_index = index | ||
| kw_to_retry = kw | ||
|
|
||
| # If currently executed keyword does not match any defined RetryKeyword -> just return | ||
| if not match_kw_retry: | ||
| return |
There was a problem hiding this comment.
that whole section seems to check if the keyword can be retried. But isn't that only relevant if the status is fail the first time?
Because on the second time, we should be sure already that we are currently retrying a keyword.
Also here, in the case we fail the first time, it would be the part, where we do all the code from start_keyword?!
…fixed some comments (#3) * refactored to pyproject, flit, ruff, etc and added tests and typing * merged pr-14 to fork, fixed some of the comments --------- Co-authored-by: René <snooz@posteo.de> Co-authored-by: Marvin Klerx <marvin.klerx@imbus.de>
|
New strategy: |
* added state for ongoing kw retry * strategy for discussions * new strategy - draft * fix retry count mechanism * retry handling + log handling * warn instead error --------- Co-authored-by: Marvin Klerx <marvinklerx20@gmail.com> Co-authored-by: Marvin Klerx <marvin@BREMBO.imbus.de>
|
@Snooz82 Please check the latest state of this PR - i have applied the new strategy discussed last week. Additionally, i have changed the initial loglevel handling a bit, but from my point of view this should match our expectation now. PS: The RetryFailed listener seems to be working also after removing the |
No description provided.