2 Replies Latest reply on Mar 6, 2014 4:08 AM by objectiser

Should unexpected error responses being recorded with a fault value in activity events?

objectiser Mar 5, 2014 12:29 PM

The activity event model enables response details to be recorded, include a 'fault' field to document when an expected fault response is returned (e.g. CustomerUnknown).

As part of the new RTGov UI, I am currently experimenting with Kibana/ElasticSearch, and how to provide useful out of the box charts to an end user. One of these charts shows the faults captured from the responses.

If an unexpected exception occurs in a switchyard app, this is recorded as a response, but without a message type - so the exception (e.g. schema validation error) would be shown in the response content, but the fault field is not set - i.e. as it is not an expected exception.

If we do provide a value in the 'fault' field, when an unexpected exception occurs, it would enable the Kibana chart to show the percentage of unexpected faults along with the expected ones, which seems a useful capability - however identifying these unexpected faults based on the missing message type is not something that can be defined in the Kibana chart.

Therefore wondering whether a default 'fault' field value should be reserved to represent an 'unexpected error'? Or should this field only be used for known faults that are defined on the service interface?

Thoughts appreciated.

Message was edited by: Gary Brown Fixed incorrect use of 'expected' instead of 'unexpected' - thanks Eric for picking up on this.

1. Re: Should unexpected error responses being recorded with a fault value in activity events?

eric.wittmann Mar 5, 2014 12:33 PM (in response to objectiser)

I think the fault field should be used for both expected an unexpected faults. To me it seems like checked vs. unchecked exceptions. You can still catch the latter and see what kind of thing it is.

Gary - is there a hidden disadvantage to including both in the fault field that I'm not seeing? If not, then it seems clear that the advantage of being able to report on it is too great to pass up.
Actions
2. Re: Should unexpected error responses being recorded with a fault value in activity events?

objectiser Mar 6, 2014 4:08 AM (in response to eric.wittmann)

I wouldn't say there is a disadvantage, although it would be good to be able to understand which faults are checked and unchecked - just to understand which are associated with the service interface.

A couple of options exist:

1) Set the fault field to a generic reserved value to indicate that an unexpected fault occurred, and the details of the fault will be provided in the content field.

2) Try to set the fault to a meaningful value representing the unexpected fault, and set a property to reflect that it is unexpected.

The benefit of (1) from a graphical visualization perspective, is that all unexpected errors get grouped into a single segment of a pie/bar chart. If each possible unexpected exception is represented differently, then this could fragment the results, making it impossible to distinguish expected from unexpected in the chart.

The benefit of (2) is that the fault field conveys more meaning.

May be a compromise is that the fault field has a reserved value (e.g. ERROR), that won't conflict with actual fault values, and is also (hopefully) understandable in many languages. As already mentioned, the main exception description will be in the content. However if there is a 'type' associated with the unchecked fault, then it could be put into a property, allowing easier analysis by rules etc.?
Actions

Go to original post