Propagate error_code and error_msg to test cases

[r-c-n]

In some cases, data.error_code and data.error_msg are only filled in test suite nodes, but not in their child nodes (test cases).

Example:

• Parent node (test suite): https://staging.kernelci.org:9000/viewer?node_id=662f5289310c66c36ceef621
• Child node (test case): https://staging.kernelci.org:9000/viewer?node_id=662f53ea310c66c36ceef87f

This makes it inviable to properly automate queries for test cases based on these parameters, as the real values are in a different node (the parent).

Wouldn't it make sense to propagate these values, if present, to all the child nodes?

[padovan]

What would this for a user evaluating regressions essentially? Seems something that will facilitate grouping?

[r-c-n]

Basically, uniformity of results, which is at the core of other processes/tasks:

If a test fails in lava due to an infrastructure error, this is encoded only in the test suite node, but users querying for test cases won't be aware of it. The results may be misleading.

This isn't currently a problem with regressions because I already worked around this issue when I wrote the code for detecting and creating them, but no code is doing that for test results.

[r-c-n]

A similar issue was already addressed previously: https://github.com/kernelci/kernelci-core/issues/2418

[nuclearcat]

Do we need to work on this topic or it is mostly completed? Or can be closed?

[r-c-n]

AFAIK no work has been done on this yet, but things may have changed after the recent changes in the modeling of the node structure. IMO it's still useful (very useful) to have this information in the test case nodes. @JenySadadia what do you think?

[JenySadadia]

Hello, Yes, it's definitely useful to have error metadata in test case nodes. On the other hand, what if a test suite has hundreds of test sets (not sure if that would ever be the case) and the LAVA raises an error? Is it meaningful to copy the same data to all the child nodes? It wouldn't be good from the database point of view.

[r-c-n]

Of course, every feature has a drawback. I'm thinking about design, other considerations (DB space, performance, optimization) should be evaluated separately. Without concrete estimations and measurements it's pointless to talk about these potential drawbacks, though --> will this feature make the DB bigger? yes. Will that have a noticeable impact? we don't know.

So it's up to the Maestro team to decide whether it's worth it to implement this or not.