ruanwenjun opened a new issue, #18224: URL: https://github.com/apache/dolphinscheduler/issues/18224
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/dolphinscheduler/issues?q=is%3Aissue) and found no similar feature requirement. ### Description The `dolphinscheduler-api` service layer historically uses `Map<String, Object>` as the return type for many service methods, mixing three semantically distinct fields into one untyped map: - `STATUS` — a `Status` enum value - `MSG` — a formatted error message string - `DATA_LIST` (or `data`) — the actual payload (entity, DTO, list, …) Controllers then call `BaseController.returnDataList(map)` to unpack this into a `Result<T>`. The pattern has several real costs: 1. **No compile-time guarantees** — controllers must "know" what payload key the service used, and what type to cast it to. 2. **Hides intent** — a `void`-equivalent method, a single-entity getter, and a list query all share the same signature. 3. **Duplicates the global error path** — `ApiExceptionHandler` (`@RestControllerAdvice`) already turns `ServiceException` into a wire-equivalent `Result(code, msg)`, so the `putMsg(map, status)` route is just a parallel error mechanism. 4. **Inconsistent within the module** — ~28 services already use the typed pattern (`AccessTokenService`, `TaskInstanceService`, `AlertGroupService`, etc.). The remaining services keep the legacy pattern alive and force every new contributor to learn both. This issue tracks finishing the migration so the legacy pattern can be removed. ### 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]
