SEZ9 opened a new issue, #12066: URL: https://github.com/apache/seatunnel/issues/12066
### Search before asking - [X] I had searched in the [feature](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22Feature%22) and found no similar feature requirement. ### Description When a REST v2 request fails, `ExceptionHandlingFilter` puts the **entire Java stack trace** into the `message` field of the JSON error body: https://github.com/apache/seatunnel/blob/dev/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/rest/filter/ExceptionHandlingFilter.java ```java errorResponse.setMessage(ExceptionUtils.getStackTrace(e)); ``` So a simple client mistake, such as omitting `jobId`, produces a response like: ```json { "status": "fail", "message": "java.lang.IllegalArgumentException: Job id is required\n\tat org.apache.seatunnel.engine.server.rest.service.JobInfoService.getJobInfo(JobInfoService.java:XX)\n\tat org.apache.seatunnel.engine.server.rest.servlet.JobInfoServlet.doGet(JobInfoServlet.java:XX)\n\tat javax.servlet.http.HttpServlet.service(...)\n\t... 40 more frames ...\n" } ``` This is a poor API contract for two reasons: 1. **The useful part is buried.** A caller that wants to show the operator what went wrong has to parse a multi-line blob and guess which line carries the message. Every other JSON field in the v2 API is a single, directly usable value. 2. **The frames describe this node, not the request.** They are already written to the server log on the very next line (`log.error("Error occurred while processing request", e)`), so nothing is lost by leaving them there. Sending them to the caller only tells whoever called the endpoint which internal classes and line numbers the master is running. ### Usage Scenario Anyone building tooling, a dashboard, or a CI check on top of the v2 REST API, and anyone reading a `curl` response by hand. Proposal: keep the exception type and message in `message` (`ExceptionUtils.getMessage(e)`, which is already the convention used by `BaseLogService` in the same module) and keep the frames in the server log where they belong. The `"status": "fail"` shape and the HTTP status codes stay exactly as they are. ### Related issues _No response_ ### Are you willing to submit a PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
