Constant Timer strange behavior when used with variables or functions

[KingRabbid]

Expected behavior

When the value of a Constant Timer references a variable or a function call the following must be preserved (as it happens for a numeric value):

1. Constant Timer runs after a PreProcessor
2. Constant Timer does NOT run as the 1st element in a JMX

I see a problem with current behavior:

1. Either the documentation should be clear about restriction to use anything else than numeric values and also implement a validation which rejects any other format value
2. Or fix the current issue(s)

Note: I think Constant Timer is used by other timers (Random ones) so they may be impacted as well.

Actual behavior

I've spotted strange behavior from Constant Timer when the value references a variable or a function call:

1. It runs as 1st element in a JMX
2. It is executed before a JSR223PreProcessor (probably before any PreProcessor)

This is not valid if the value is entirely a numeric constant; this is also not valid for a JSR223Timer.

What I can see:

1. Because Constant Timer's are executed as 1st elements from the tree when they are attached to the ThreadGroup then they throw NullPointerException because the variable is unknown (see JMX for tree structure)
2. On Constant Timer branch in case of Flow Control Action 2 the timer is executed before the JSR223PreProcessor (visible in log and sampler timestamps) => this is not as per documentation
3. Initially I've spotted the issue having Flow Control Action samplers and I thought it's an issue with them or in this combination; next I've used JSR223Sampler elements but outcome is the same.

jmeter.log
ConstantTimer-bug.zip

Steps to reproduce the problem

Attaching sample JMX; I do recommend to set log level to DEBUG to see sequence of execution better.

JMeter Version

5.6.2, 4.0

Java Version

OpenJDK 64-Bit v17.0.9

OS Version

Windows 11

[vlsi]

javax.script.ScriptException: javax.script.ScriptException: java.lang.NullPointerException: Cannot invoke method toLong() on null object
	at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:158) ~[groovy-jsr223-3.0.17.jar:3.0.17]
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:231) ~[java.scripting:?]
	at org.apache.jmeter.functions.Groovy.execute(Groovy.java:123) [ApacheJMeter_functions.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.engine.util.CompoundVariable.execute(CompoundVariable.java:139) [ApacheJMeter_core.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.engine.util.CompoundVariable.execute(CompoundVariable.java:114) [ApacheJMeter_core.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.testelement.property.FunctionProperty.getStringValue(FunctionProperty.java:104) [ApacheJMeter_core.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.testelement.property.AbstractProperty.getLongValue(AbstractProperty.java:128) [ApacheJMeter_core.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.testelement.AbstractTestElement.getPropertyAsLong(AbstractTestElement.java:393) [ApacheJMeter_core.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.timers.ConstantTimer.iterationStart(ConstantTimer.java:108) [ApacheJMeter_components.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.control.GenericController.fireIterationStart(GenericController.java:412) [ApacheJMeter_core.jar:5.6.2-SNAPSHOT]
	at org.apache.jmeter.control.GenericController.fireIterEvents(GenericController.java:404) [ApacheJMeter_core.jar:5.6.2-SNAPSHOT]

The root cause is that constant timer evaluates delay at the "iteration start":

jmeter/src/components/src/main/java/org/apache/jmeter/timers/ConstantTimer.java

Line 108 in 9b250b6

delay = getPropertyAsLong(DELAY);

It is more-or-less the same as #6165 (comment)

[vlsi]

The list of impacted classes is: ConstantTimer (and derived classes), CompareAssertion, CSVDataSet, RandomVariableConfig