API error reporting
Assignee
Tomas Horsky
Tomas HorskyReporter
Pavel Salamon
Pavel SalamonSprint
None
Description
Steps to reproduce
None
Activity
Show:
Dominik Janura September 10, 2020 at 11:32 AMEdited
Tested OK with various error states in cloveretl.server-CLO-19440 #83
Tomas Horsky September 10, 2020 at 7:42 AM
Done
{
"timestamp" : "2020-09-10T09:30:19.332+02:00",
"status" : 404,
"error" : "Not Found",
"message" : "Monitor was not found",
"path" : "http://node1:11981/clover/api/rest/v1/dashboards/1/monitors/43",
"details" : {
"messages" : [
"Monitor was not found"
]
}
}
Pavel Salamon September 9, 2020 at 10:30 AM
Grooming:
path should return full url
Tomas Horsky September 7, 2020 at 6:09 AM
The "message" property now contains formatted messages from the exception tree. The "detail.messages" is an array of individual messages.
Stack trace (the "stack" property) is present only in development environment, OR if the error is an uncaught exception turned into 500 Internal server error.
The error mentioned in issue description now looks like this.
{
"timestamp" : "2020-09-07T07:56:58.848+02:00",
"status" : 400,
"error" : "Bad Request",
"message" : "Could not create monitor\n could not execute statement\n Data truncation: Data too long for column 'name' at row 1",
"path" : "/clover/api/rest/v1/dashboards/1/monitors",
"details" : {
"messages" : [
"Could not create monitor",
"could not execute statement",
"Data truncation: Data too long for column 'name' at row 1"
],
"stack" : [
"com.cloveretl.server.api.rest.v1.common.exception.BadRequestException: Could not create monitor",
" at com.cloveretl.server.api.rest.v1.dashboards.MonitorService.createMonitor(MonitorService.java:66)",
" at com.cloveretl.server.api.rest.v1.DashboardsApiController.createMonitor(DashboardsApiController.java:61)",
...cut...
"Caused by: javax.persistence.PersistenceException: org.hibernate.exception.DataException: could not execute statement",
" at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154)",
" at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181)",
...cut...
"Caused by: org.hibernate.exception.DataException: could not execute statement",
" at org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:52)",
" at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)",
...cut...
"Caused by: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Data too long for column 'name' at row 1",
" at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:104)",
" at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:975)",
...cut...
]
}
}
There is a follow up issue https://cloverdx.atlassian.net/browse/CLO-19672#icft=CLO-19672 - handling of the lack of user permissions.
Jaroslav Urban September 3, 2020 at 8:20 AM
Grooming:
@Tomas Horsky & @Martin Zatopek will call and agree on details
Users should get reasonable error messages whenever possible.
An example:
I tried creating a monitor with too long name (257 chars) and got error "Could not create monitor". That doesn't help me to recover - I do not know the reason of failure, so I don't know what I need to fix to succeed.
Some of the errors we can prevent by improving request validations. But there will still be errors happening in some of the inner layers, and we need to improve their error reporting.