Rudder

in this case:
class prefix is command_execution__sbin_service_rsyslog_restart
canonified_class_prefix is command_execution__sbin_service_rsyslog_restart
and detected technique is my_test_technique

and it is getting field in the file R: ^my_test_technique;;service_restart_rsyslog;;.*
which should not match anything

/var/rudder/cfengine-community/bin/cf-agent -V
CFEngine Core 3.6.0

Upgrading agent to 3.0 changes the behaviour:
reports is bogus

R: @@${report_data[1]}@@result_repaired@@${report_data[3]}@@${report_data[4]}@@${report_data[5]}@@2016-05-25 14:11:12+00:00##4293df6e-c63b-4ece-84dd-50abafc092ca@#Execute the command /sbin/service rsyslog restart was repaired

class report_data_read, even if number_lines is equal0

I have found a way to fix this. Looking at this part of the code:

vars:
...
    (logger_rudder_final_resfile_repaired|logger_rudder_temp_resfile_kept.!logger_rudder_temp_resfile_repaired.final_resfile_exists)::
...

      # 4/ Once the final expected reports file has been expanded, read in our array
      "number_lines" 
        int        => getfields("^${current_technique_report_info.technique_name};;${c_class_prefix};;.*", "${expected_reports_file}", ";;", "report_data");

  classes:
      "report_data_read" expression => isgreaterthan("${number_lines}","0");

...

  methods:

    report_data_read::

      "any" usebundle => _rudder_common_reports_generic("${report_data[1]}", "${c_class_prefix}", "${report_data[3]}", "${report_data[4]}", "${report_data[5]}", "${message}"),
        classes    => classes_generic("logger_rudder_${c_class_prefix}");

And analysing the verbose output from the agent, it became clear to me that the report_data_read class is being set on the first pass through this bundle, despite the fact the number_lines has not yet been populated. I can only assume that ${number_lines} resolves to some random number that happens to be > 0.

A simple workaround is to use the same class expression on the classes promise that examines number_lines as on the vars promise that populates number_lines. I have successfully tested this workaround, and ncf reporting behaves as expected, and no bogus ncf report is generated (I previously successfully reproduced the problem on a Rudder 3.2/ncf 1.x setup).

I really don't understand this fix as all these classes are defined at the first bundle run, and then remain for the rest of the execution (so, when we get the extra report, the classes are already all defined

(tinkering with the promises)

Ok ! it does make sense, in a weird way. If the files .res and .tmp were already correct, logger_rudder_final_resfile_repaired is not defined, so it relies on the second part of the class condition (logger_rudder_temp_resfile_kept.!logger_rudder_temp_resfile_repaired.final_resfile_exists) which contains only global classes + final_resfile_exists that is a local class, defined after report_data_read
So, the value used for ${number_line} is the value that was defined at the previous bundle execution, hence the bogus report

Good catch Jon