Rudder

Those are used to define unique prefixes for the classes_noop bundle calls, used when a condition is applied on a method or block and is not verified at runtime, resulting in a report_na report.

As a technique may be use "multiple times", each reporting must be re-evaluated whenever the technique is called, without being influenced by the previous technique calls.
That is why the current implementation uses a class_prefix at the technique level, defined by the concatenation of the directives parameters, this way, a conflict will only occur if two directives are strictly identical.
Still, it over-complexify the cfengine code, leading to the following generated code:

bundle agent call_ntp_technique_d86ce2e5_d5b6_45cc_87e8_c11cca71d907(c_name, c_key, report_id, args, class_prefix, name, version, architecture, provider) {

  methods:
    "d86ce2e5-d5b6-45cc-87e8-c11cca71d907_${report_data.directive_id}" usebundle => _method_reporting_context_v4("${c_name}", "${c_key}", "${report_id}");
    "d86ce2e5-d5b6-45cc-87e8-c11cca71d907_${report_data.directive_id}" usebundle => _classes_noop(canonify("${class_prefix}_package_present_${c_key}"));
    "d86ce2e5-d5b6-45cc-87e8-c11cca71d907_${report_data.directive_id}" usebundle => log_rudder("Skipping method 'Package present' with key parameter 'htop' since condition 'false' is not reached", "htop", canonify("${class_prefix}_package_present_${c_key}"), canonify("${class_prefix}_package_present_${c_key}"), @{args});

}

2 bigs issues here:

• The resulting conditions of the skipped method are incorrect if wanted, they are unguessable before runtime as they are based on runtime computation of the directive parameters.
  • Note that the documentation never introduce resulting conditions for "skipped" methods, so there should not be any existing user technique using them.
  • The exact defined conditions are: truncate(<concat(techniques_params)>, 1000) + "_" + method_prefix + "_" + component_value + "_noop"
• Each bundle must take a class_prefix as input which is pretty much useless as its only purpose it to be "a unique internal id per technique call" and is not exposed to the user.
  • As a side effect, the technique will be bugged when one or more of its parameters are empty or undefined (can happen if run manually or with rudderc testing, in a classic run, the webapp is responsible to validate that everything is correct beforehand).

At least two solutions can quite easily be implemented:

• Dropping the result conditions when a method is skipped: easiest one, as the resulting conditions are not documented, we could just force a result_na report and not define any resulting condition
• Document and define a resulting condition: for instance method_prefix + "_" + component_value + "_na", and base the generate a force a result_na report.

In the two cases we should be able to work without the need of any unique identified per technique call as the reporting can be hard-coded.
Still, the choice to support or drop the NA resulting conditions must be evaluated as going back afterward will be hard.