Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Listener's start_user_keyword modifications only affect subsequent executions, not current keyword run #5353

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

Closed
Lavinu opened this issue Mar 5, 2025 · 3 comments

Comments

@Lavinu
Copy link

Lavinu commented Mar 5, 2025

Problem Description

When modifying a keyword's body via the start_user_keyword listener method, changes do not take effect for the current execution of the keyword. The modified behavior only applies when the keyword is called again in subsequent executions. This prevents real-time keyword suppression/dynamic modification during test runs.

Steps to Reproduce

  1. Create a listener that modifies keyword definitions in start_user_keyword:
    KeywordSuppresor.py

    class KeywordSuppressor:  
        ROBOT_LISTENER_API_VERSION = 3  
        def __init__(self, kw_name):  
            self.keyword_to_skip = kw_name  
        def start_user_keyword(self, data, implementation, result):
            if data.name == self.keyword_to_skip:
                resource = implementation.owner
                for kw in resource.keywords:
                    if data.name == kw.name:
                        kw.body.clear()
                        kw.body.create_keyword(
                            "Log",
                            [
                                f"ROBOT LISTENER: KeywordSuppressor - the keyword '{kw.name}' is requested to be skipped."
                            ],
                        )
  2. Create Testcase and Resource file
    Keyword.resource

    *** Keywords ***
    Resource Keyword1
       Log    Hello Resource Keyword1
    
    Resource Keyword2
       Log    Hello Resource Keyword2
    

    Test.robot

    *** Settings ***
    
    Resource    Keyword.resource
    
    *** Test Cases ***
    Log Hello World1
        Robot Keyword1
        Resource Keyword1
        Robot Keyword2
        Resource Keyword2
    
    Log Hello World2
        Robot Keyword1
        Resource Keyword1
        Robot Keyword2
        Resource Keyword2
    
    Log Hello World3
        Robot Keyword1
        Resource Keyword1
        Robot Keyword2
        Resource Keyword2
    
    
    *** Keywords ***
    Robot Keyword1
        Log    Hello Robot Keyword1
     
    Robot Keyword2
        Log    Hello Robot Keyword2  
    
  3. Call
    robot --pythonpath . -b rlog --listener ./xxx/KeywordSuppressor.py:'Resource Keyword1' ./xxx/Test.robot

Expected Behavior

Modifications made in start_user_keyword should immediately affect the current execution of the keyword being processed.

Actual Behavior

Changes only take effect on subsequent calls to the keyword.
Image

Need confirmed if this is intentional design or a limitation of the listener API

Environment

Robotframework 7.1
Python Version 3.9.9

@pekkaklarck
Copy link
Member

Does modifying the implementation object directly work?

@pekkaklarck
Copy link
Member

A bit more background. The implementation you got is a robot.running.UserKeyword instance that is going to be executed. If you modify its body, changes ought to be taken into account. To avoid this kind of changes affecting subsequent calls of the same keyword, the actual implementation object you get is a copy of the keyword that the resource file contains.

In your code you find the keyword from the resource file and modify that. Also these keywords are robot.running.UserKeyword instances. Due to the reasons explained above, changing them doesn't affect the current keyword but changes the subsequent calls.

Notice also that the data object contains the data that's used in the test and keyword name and arguments are exactly in the format used there. Thus when matching data.name, you should take at least case-sensitivity into account. It would probably be safer to use implementation.name instead.

@pekkaklarck
Copy link
Member

No new info. Closing.

@pekkaklarck pekkaklarck closed this as not planned Won't fix, can't repro, duplicate, stale May 7, 2025
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

2 participants