Consider specifying problem type for "unrecognized aggregation job"

[branlwyd]

Similarly to the "unrecognizedTask" error token, a request might reference a nonexistent/unknown aggregation job. It may be useful to specify an "unrecognizedAggregationJob" or similar error token for this case.

[cjpatton]

I noticed this as well. In fact, there are a few error cases we're not covering right now. I wonder if we really need to cover them all? In any case I am not opposed to adding this one.

[branlwyd]

I think we probably don't need to specify many errors; my thinking, at least, is that we only need to specify the error types that, when communicated, will cause a difference in behavior on the part of the receiver which is relevant to interoperability. (Certainly, implementations might choose to have more granular errors to e.g. ease debuggability, but this can be left implementation-specific.)

I'm not sure if that's the right bar to justify a new error code; it makes sense to me since it follows the principle of "specify minimal behavior to allow interoperability."

Perhaps we should eventually decide what justifies an error code being specified, and do a larger pass over the error codes to (de-)specify things that are not needed?

[branlwyd]

(in any case, the general principle of what should/should not be an error condition is probably outside the scope of this issue. I'm happy enough trying to specify unrecognizedAggregationJob for now; if you'd like to specify any of the other error cases you mention, I can do so as well.)