FrankChen021 commented on issue #13123: URL: https://github.com/apache/druid/issues/13123#issuecomment-1257385499
> > For example, a task failed because there were no valid input records. Now, that can be caused by a bad timestamp spec, a badly configured filter, or because data has multiple values for some column in each row. We don't want to put all these reasons in the database when storing task result status. I can store `NO_VALID_INPUT_RECORDS` as the error code and then map it to a nice error message in the application. What do you think? IMO, in this example, `NO_VALID_INPUT_RECORDS` is still hard for problem solving. When facing such error code, we still don't know what kind of exception that Druid encounters, is it due to bad timestamp spec or due to badly configured filter or sth else? We still need the error message to figure out what happened. So, error code needs to be more precise. Even if we split such error code `NO_VALID_INPUT_RECORDS` into 3 error codes to match each case, I think we still need to put the error message in the database. Because error message gives exact message to help us address problems. For example, if a `BAD_TIMESTAMP` error is raised, without the exception message, we don't know what the error input is, and we don't know we know where the source is and have no idea where we should fix the problem. But I think this is out of the scope of the main topic. I totally agree that we should add a global error code to the exception, but how to design an error code is more complicated. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
