Erroneous condition for Trace/Metric/Log Pipelines evaluates to TLSCertificateInvalid by default

[TeodorSAP]

Description
When there's an error returned within the status.go evaluateConfigGeneratedCondition function, if its type is not handled within the function, it gets by default handled by the conditions.EvaluateTLSCertCondition() function, which evaluates it to a TLSConfigurationInvalid error reason.

Criterias
Find some alternative method of defaulting the condition reason in case of error, maybe by introducing a new UnknownError reason, or something that would signal the developer that the specific error type is not handled anywhere, rather than setting it to TLSConfigurationInvalid and further confusing the developer.

Reasons

It's time-consuming during debugging to figure out what really happened in such a scenario, and might confuse customers as well if some unknown error reaches production, getting evaluated, handled, and alerted as a TLSConfigurationInvalid type of error.

Attachments

telemetry-manager/internal/reconciler/tracepipeline/status.go

Line 99 in 335ea34

return conditions.EvaluateTLSCertCondition(err)

telemetry-manager/internal/conditions/tls_cert_conditions.go

Line 23 in 335ea34

return metav1.ConditionFalse, ReasonTLSConfigurationInvalid, fmt.Sprintf(commonMessages[ReasonTLSConfigurationInvalid], errValidation)

Release Notes

[cosmastech]

Would you suggest returning the new error (UnknownError) from evaluateConfigGeneratedCondition() or from EvaluateTLSCertCondition()?

[TeodorSAP]

I think from evaluateConfigGeneratedCondition(), but we need to refactor the code accordingly. Sorry for the delay @cosmastech, I have not received any notification.