Fixes #23652: iteration in technique editor with package method don't report correctly #1413
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://issues.rudder.io/issues/23652
This change adds a variability based on the key for generic methods.
To allow multiple execution of generic method based on service command and package, we introduced a stack for evaluation & reporting, that uses generic method id + directive + rule as an id
This solves the issue of multiple evaluations, yet it does not work with reporting: a list of package to install, with the first in repair and the other in success return repair for all the package, breaking the reporting
We have a facility to unwrap the list in the generated technique
27 bundle agent iteration_gm_1(c_name, c_key, report_id, name, version, architecture, provider) { 28 methods: 29 "c3974f2e-d9e9-4527-ab5f-e0add1c52318_${report_data.directive_id}" usebundle => _method_reporting_context_v4("${c_name}","${c_key}","${report_id}"); 30 "c3974f2e-d9e9-4527-ab5f-e0add1c52318_${report_data.directive_id}" usebundle => package_present("${name}","${version}","${architecture}","${provider}"); 31 }
which was introduced in https://issues.rudder.io/issues/20603
so, we could be insensitive to iteration if we add the key to the report
For packages, command and services, report_id and method_id are both used for defining classes & report condition (and I suspect that one in use in place of the other more than once); so adding in them the key allow unicity
This is was this change does and fixes the reporting issue
It needs to be more throughly tested, especially for the result condution of the GM, and for techniques, and services & command