Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

Repeater using dynamic list error #3731

rpallares ·

Hello,

We recently found an issue concerning repeaters and dynamic variable. In some cases the dynmaic variable update is not taken by the repeater below.

Steps to reproduce

  1. Create a configuration
  2. Add a variable repeatedValues containing "val1,val2"
  3. Add a step that update the variable with the script below
groovy:
def values = vars.get("repeatedValues").asList();

if(!values.contains("val3")) {
  logger.info("Add default value val3");
  values.add("val3");
}
if(!values.contains("val4")) {
  logger.info("Add default value val4");
  values.add("val4");
}

vars.get("repeatedValues").setValue(values.join(","));
build.flushVariables()

I don't know if build.flushVariables() is necessary, but as we have strange comportment I keep it.

  1. Add another step called "== Loop" that is repeated using ${vars.getValue("repeatedValues")}

  2. Add a step into "== Loop" that juste log the current parameter

  3. Execute the configuration and observe that the loop is only repeated twice (val1 and val2).

  4. Go into the build overview > Variable and see that the repeatedValues variable contain the expected values (val1,val2,val3,val4)

Workaround

We don't understand if there is a underlying reason to not get dynamically the variable update into the repeater but we found a workaround.
To have the expected repetition:

  1. encapsulate the repeated "== Loop" into a Sequentil composition step "== Loop root"
  2. Execute the configuration
  3. We have the four repetition as expected into the "== Loop root"

Is that issue is identified?
Do we really need to call build.flushVariables()?
Is there a cleaner way to workaround that issue?
Have you an explanation to avoid that kind of comportment?

Regards,
Rafael

  • replies 1
  • views 193
  • stars 0
robinshen ADMIN ·

This is expected behavior as QB will need to evaluate step repetitions to instantiate all child step instances before executing the parent step. This is why you only saw two instances of repeated steps without using "== Loop root".

The build.flushVariables() is not necessary here.