chore(history): populate errorType for incidents#1031
Conversation
yanavasileva
requested review from
HeleneW-dot
and removed request for
yanavasileva
HeleneW-dot
left a comment
HeleneW-dot
left a comment
There was a problem hiding this comment.
Lgtm, just requesting change for one question regarding whether we could differentiate further for the no retries incident type 🚀
| String type = c7Incident.getIncidentType(); | ||
| String msg = c7Incident.getIncidentMessage(); | ||
|
|
||
| if (msg == null) { |
There was a problem hiding this comment.
Could the message also be an empty string?
There was a problem hiding this comment.
If it's an empty string, I think it means it was set like that on purpose, so I think it makes sense to return UNKNOWN rather than falling back to the incident type.
There was a problem hiding this comment.
Yes, meant that we can catch this here too to return early with unkown 👍
| if (msg == null) { | ||
| // fall back to job‑retries semantics | ||
| if (Incident.FAILED_JOB_HANDLER_TYPE.equals(type) || Incident.EXTERNAL_TASK_HANDLER_TYPE.equals(type)) { | ||
| return JOB_NO_RETRIES; |
There was a problem hiding this comment.
Q: could we differentiate between EXECUTION_LISTENER_NO_RETRIES and TASK_LISTENER_NO_RETRIES` here? Or doe they not map like that
There was a problem hiding this comment.
As far as I understand, both map to JOB_NO_RETRIES.
There was a problem hiding this comment.
Ah I think I read it the wrong way around, all good then
2 participants
Rel to #432
Pull Request Template
Description
Type of Change
Testing Checklist
Black-Box Testing Requirements
DbClient,IdKeyMapper,..impl..packages except logging constants)ArchitectureTestvalidates these rules)Test Coverage
Architecture Compliance
Run architecture tests to ensure compliance:
mvn test -Dtest=ArchitectureTestIf architecture tests fail, refactor your tests to use:
LogCapturerfor log assertionscamundaClient.new*SearchRequest()for C8 queriesDocumentation
Checklist
Related Issues