langpacks
langpacks copied to clipboard
Error type consistency
Should standardize the error_type
field between langpack implementations. I think it's more useful to be the "exception type" (whatever that means in the given language) if possible.
https://github.com/algorithmiaio/langpacks/blob/master/python/template/bin/pipe.py#L70 https://github.com/algorithmiaio/langpacks/blob/master/ruby/template/bin/pipe.rb#L28
Looks like error_type
is no longer documented on http://docs.algorithmia.com/#input-output , the original purpose of using an enum like AlgorithmError
(like in the python example) was to enable clients to implement retry strategies according to the received value inside the error_type
field (aka: was there a potentially transient error in the algorithmia infrastructure? or was there an error on the inside of the algorithm container). This can only reasonably be accomplished via a script-readable mechanism like enum or status code.
If there is a different mechanism for detecting retry-ability client-side or if such retry strategy hasn't been found to be useful then this field can be co-opted for a human-readable "exception type".
Correction @argoday: long ago we had discussed what you described with error_type
, but it was never implemented (outside of common message passing). For langpacks we added the field to minimally surface algorithm errors from errors that occur within langserver so that we could finally distinguish the errors in internal logs (i.e api_log), but to this day error_type
is not exposed through the public API.
- I would very much like to expose
error_type
- for the reasons @Argoday outlined - I agree @pmcq that the runners should capture the exception type and use that as the
error_type
(with something likeAlgorithmError
as a fallback default if we don't have meaningful type, e.g.String
) while still reserving one or moreerror_type
values for Algorithmia system errors. The caveat is that aerror_type
name collisions are possible. Today I could write a ruby algorithm that throws an exception with classSystemError
, and it would wind up in the wrong error metrics. So perhaps we need yet-another-field to distinguish this. :-/
Yeah I think there's a need of some discussion on what the right approach is (before creating issue I had a feeling it'd be yet-another-field) but we've talked about error codes as an option as well. Anyway, just didn't want to lose track of this.
my mistake - I forgot we only had error_type
in the internal messages