fatmanverse commented on PR #12922:
URL: https://github.com/apache/seatunnel/pull/12922#issuecomment-6557065577
Thanks @SEZ9. All six points are in the current head 74235a4c2; pointers
below (line numbers at that head).
1. **Validate before submit.** `JobInfoService#submitJobs`
(JobInfoService.java:504) first maps every entry through
`validatedSubmitJobsParams` into a list (lines 508-511), and only then loops
over the entries calling `submitJobInternal` (lines 513-523).
`validatedSubmitJobsParams` (line 537) runs the savepoint/jobId check, the
dry-run check, `validateCheckpointRestoreRequest` (restoreMode), the blank
`restoreSourceJobId` check and the `long` checks of `jobId` /
`restoreSourceJobId`. So a bad entry N returns 400 before entries 0..N-1 are
submitted. What can still fail after earlier entries are on the cluster are
errors that depend on the job config or the cluster (an invalid config, a
missing savepoint); the method Javadoc and the docs say so.
2. **jobId messages.**
- Blank `jobId` with `isStartWithSavePoint`: `checkStartWithSavePoint`
(RestUtil.java:103) now uses `StringUtils.isBlank`, so `""` and `" "` fail
with `Please provide jobId when start with save point.`, the same message as
the v1 URL path.
- Non-integer string `jobId` / `restoreSourceJobId` (including an
oversized one such as `"99999999999999999999"`): `checkLongParam`
(JobInfoService.java:567) fails with `'jobId' must be a long integer` (or
`'restoreSourceJobId' ...`), not a raw `NumberFormatException` text and not the
`restoreSourceJobId is required ...` message.
- A JSON *number* that is fractional, an exponent or outside the `long`
range (`1.5`, `1e3`, `9223372036854775808`) is rejected earlier by
`toStringParams` (RestUtil.java:160) with `'params' number values must be
integers within the long range`. That message names `params` but not the key,
on purpose (see 5). I can name the key when it is one of the known keys
(`jobId`, `restoreSourceJobId`) if you prefer; tell me and I'll add it.
3. **Tests.**
-
`RestUtilSubmitJobsParamsTest#testNullValueIsSkippedAndEmptyStringIsKept`:
`"jobId": null` falls back to the default, `"jobName": ""` is kept.
- `RestUtilSubmitJobsParamsTest#testNestedParamValuesAreRejected` (object
and array values) and `#testNumberValuesMustBeLongIntegers` (`Long.MAX_VALUE`
accepted; `1e3`, `1.5`, `Long.MAX_VALUE + 1` rejected).
-
`JobInfoServiceSubmitJobsTest#testInvalidLaterEntryRejectsTheWholeRequest`: a
valid first entry followed by 9 kinds of invalid second entry, including the
nested value `{"jobName": {"a": 1}}`, `{"jobId": 1.5}`, `{"jobId": "abc"}`, a
bad `restoreMode` and blank `restoreSourceJobId`. Each case asserts that
nothing was submitted, the first entry included.
- `RestApiIT#testSubmitJobsRejectsAnInvalidLaterEntryBeforeSubmittingAny`
runs 3 of these cases against a real cluster on both the v1 and v2 URLs, and
asserts HTTP 400 and that the first job does not exist.
4. **Docs.** The `params` table in
`docs/{en,zh}/engines/zeta/rest-api-v1.md` and `rest-api-v2.md` now types
`jobId` and `restoreSourceJobId` as `string | number` and
`isStartWithSavePoint` as `string | boolean`, and adds `restoreMode` and
`restoreSourceJobId` rows. The paragraph below the table lists the accepted
value types, the `null` skip, the 400 cases and the validate-before-submit
behaviour.
5. **Client key in the log.** The nested-value and number messages name only
the JSON type, never the client's key or value. `toStringParams` documents
this, and `testNestedParamValuesAreRejected` uses a key containing
`do-not-echo\n` and asserts the exact message. The only key names that appear
in messages are the server-side constants `jobId` and `restoreSourceJobId`
(point 2).
6. **Rename.** The JSON path calls `RestUtil#buildRequestParamsFromJson(Map,
Map)` (RestUtil.java:93); the `buildRequestParams(Map, Map)` overload does not
exist at this head. `buildRequestParams(Map, String)` is only the v1 URL path
(`RestHttpPostCommandProcessor`), and its Javadoc explains why that one
URL-decodes and the JSON one does not.
--
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]
