wazo-call-logd call log generation failures missing root cause information
Description
wazo_call_logd.cel_interpretor.LocalOriginateCELInterpretorimplementation currently sometimes return incomplete call logs silently(without relevant logging) when expectations are unmet. This leads to call log generation failures that are hard to debug.
e.g. wazo_call_logd.cel_interpretor.LocalOriginateCELInterpretor.interpret_cels
Here, if any of 4 expected CEL events are missing for some channels, an incomplete call log is returned silently, with no errors logged at this point, even if the call log is not yet valid and does not have the minimal required information. The resulting call log generation failure will yield an error about the missing information without indicating the true cause(missing expected CEL for a specific channel in the CEL sequence).
Suggestions to improve user-facing behavior and debugging cost:
raise exceptions when critical information is missing from CELs or when the current implementation cannot support the call scenario described by the CEL sequence; unmet expectations and specific failure condition should be explicitly logged for debugging;
it’s better for users to have a call log with some basic information than none at all, so if critical information can be interpreted from CEL sequence, but some non-critical information fails to be interpreted, it is better to still generate a valid call log while also logging the error conditions encountered
wazo_call_logd.cel_interpretor.LocalOriginateCELInterpretorimplementation currently sometimes return incomplete call logs silently(without relevant logging) when expectations are unmet. This leads to call log generation failures that are hard to debug.e.g.
wazo_call_logd.cel_interpretor.LocalOriginateCELInterpretor.interpret_celsHere, if any of 4 expected CEL events are missing for some channels, an incomplete call log is returned silently, with no errors logged at this point, even if the call log is not yet valid and does not have the minimal required information. The resulting call log generation failure will yield an error about the missing information without indicating the true cause(missing expected CEL for a specific channel in the CEL sequence).
Suggestions to improve user-facing behavior and debugging cost:
raise exceptions when critical information is missing from CELs or when the current implementation cannot support the call scenario described by the CEL sequence; unmet expectations and specific failure condition should be explicitly logged for debugging;
it’s better for users to have a call log with some basic information than none at all, so if critical information can be interpreted from CEL sequence, but some non-critical information fails to be interpreted, it is better to still generate a valid call log while also logging the error conditions encountered