Being able to continue, not fail, if a WHILE loop limit is reached would sometimes be convenient. It would allow running a block of keywords a certain number of times or a certain amount of time. We already have Repeat Keyword that behaves that way so there clearly are use cases for such functionality. Being able to control the failure message that is used if the loop fails after the limit, as proposed in PR #4561, sounds like a useful enhancement as well.

Related to the design, the main questions are 1) what should the new control option be named, 2) what behavior it should support, and 3) what should the possible values be called. I comment all these below:

1. This is somewhat similar situation as running processes and waiting for them to terminate. Our Wait For Process has arguments timeout and on_timeout, and following that pattern WHILE could have limit and on_limit. If we want to make failure message if the limit is reached configurable, that could possibly be on_limit_message or something similar. If setting the message would be considered rare, we could also support on_limit=fail:<message>, but having a separate config option would probably be more clear.

2. The description proposes making it possible to fail, continue or run a specified keyword if the limit is reached. Failing and continuing sound good to me, but running a keyword feels too complicated and not that often needed. If you want to run a keyword if the the loop ends, you can simply have it after the loop. And if you want to run a keyword if the loop fails, you can wrap the loop with a TRY/EXCEPT structure. It would also make parsing a lot more complicated if we needed to support something like on_limit=Keyword Name    argument. I thus believe it would be enough to just support failing (default) and continuing. That said, I still believe the option should be on_limit=<value> and not something like continue_on_limit=True to allow supporting more values in the future if needed.

3. If we only support failing and continuing, I believe good values would be fail and continue, case-insensitively. continue is also the value that the aforementioned on_timeout accepts. The description has a valid point that CONTINUE already has a special meaning as a statement inside the loop, but I don't believe there's too big risk of confusing. That said, I'd be fine using fail and pass as well. They would match the actual status of the loop nicely.

I totally agree with your reply !

I think that, firstly, we can focus on the on_limit paramater with the following accepted values : pass, fail and continue (case insensitive). This would be a good basis prior to designing the "custom failure message" feature.

To formalize this on_limit parameter, I imagined some potentials acceptance tests :

*** Test Cases ***

Continue if limit is reached
    WHILE    True    limit=5    on_limit=continue
        Log     Test
    END

Continue if limit is reached case-insensitive
    WHILE    True    limit=5    on_limit=cONTINUe
        Log     Test
    END

Continue if limit is reached with pass
    WHILE    True    limit=5    on_limit=pass
        Log     Test
    END

Continue if default limit is reached case-insensitive
    WHILE    True    on_limit=PaSs
        Log     Test
    END

Fail if limit is reached
    WHILE    True    limit=5    on_limit=fail
        Log     Test
    END

Invalid value for on limit parameter
    [Documentation]     FAIL Invalid WHILE loop parameter 'on_limit': Invalid string 'invalid'. Accepted strings are 'continue', 'pass' and 'fail' (case-insensitive)
    WHILE    True    limit=5    on_limit=invalid
        Log     Test
    END

What do you think of theses acceptance tests ?

I think that the error raised in the last acceptance test can be improved.

I also think that we should have an acceptance test verifying the behavior of the WHILE loop when on_limit is placed before limit. In my opinion, such WHILE loop should not raise an error.

Quick comments:

1. I was thinking we'd either use pass or continue to mean that execution can continue after the loop after the limit is reaches. You have them as separate options. What semantics they would have?

2. I don't think we need to validate the order of limit and on_limit. They look and act like named arguments with keywords and their order isn't meaningful either.

3. One thing to consider is making the condition optional so to allow using

   WHILE    limit=1minute    on_limit=continue
        ...
   END
   

   instead of

   WHILE    True    limit=1minute    on_limit=continue
        ...
   END
   

On the first point, I agree with you, there should not be a behaviour difference between on_limit=pass and on_limit=continue, I'm sorry if my last comment wasn't clear.

I also agree with the two other points.

What do you think is the next step? Maybe submitting a first PR and then iterate on it?

I would suggest using BREAK instead of CONTINUE. This is more in line with the normal loop terminology.

This is also the keyword you would use if you implement similar functionality by yourself within the loop:
IF $counter > $limit BREAK

Sorry for a bit late reply. Quick comments:

1. It's true that BREAK makes more sense than CONTINUE in this context, but I got a feeling PASS would be better. The default is to FAIL and PASS matches it nicely. I don't think it makes sense to have two options that mean the same thing.

2. I believe there should be a separate on_limit_message=<msg> option for controlling the message that is used if loop fails for the limit. It's more explicit than on_limit=FAIL:<msg>. This should get its own issue.

3. As I commented earlier, making the condition optional simplifies some usages. I believe we should allow omitting it also when there's no explicit limit. This should also get its own issue.

4. If we agree on design, the next step is implementation. Are you @asaout still interested to provide a PR or PRs? It would be best to have separate PRs for each new functionality (on_limit, on_limit_message, optional condition).

I created two other issues for the on_limit_message option (#4575) and for the optional condition (#4576). For on_limit, I think that we can stay on this issue.

Providing PRs still interest me ! I think I will firstly try to provide a PR for on_limit_message issue (#4575) if we all agree on the design.

Thanks for the PRs! I won't have time to review them now, but I assign this issue and related #4575 and #4576 to RF 6.1 scope to make sure they aren't forgotten.

I ought to have time for review next week or latest the week after. I still need to release RF 6.0.2 first so that we can start active RF 6.1 development and can merge PRs directly to master.

Oh, there weren't new PRs yet, only new issues. My bad, I should have read the messages above more carefully.

Anyway, it's awesome if you are interested to provide PRs. I consider this issue the most important one as it adds totally new functionality, but feel free to start from any WHILE loop related enhancement. You already have PR #4561 that implements #4575 so starting from that probably makes most sense. Perhaps #4576 could be next, because then all tests for this enhancement don't need to use True.