DanielLeens commented on PR #11597: URL: https://github.com/apache/seatunnel/pull/11597#issuecomment-5645160314
Quick correction to my Aug 25 comment: the head has actually moved since then, and the picture has changed. Two new commits landed after Aug 25: a merge from `dev` (`a7ec7b47`) and, on Sep 9, `c176adce` — "Fix ambiguous forEach overload in RunningJobSlotUsageBuilderTest", which is exactly the `Mockito.doAnswer(...).forEach(Mockito.any())` compile-ambiguity I flagged as the Aug 24 blocker. I re-checked: that fix works. `seatunnel-engine-server` test-compile is no longer broken, and the reactor is no longer red purely because of a shared compile step. However, the fresh run on `c176adce` (https://github.com/apache/seatunnel/runs/102569612682, actual logs at https://github.com/DanielLeens/seatunnel/actions/runs/34351645773) still shows `Build: fail`, for a different and more relevant reason: - `engine-v2-it` (both JDK 8 and 11) fails in `RestApiIT.testGetRunningJobSlotUsage`: ``` java.lang.IllegalStateException: Cannot parse object because no supported Content-Type was specified in response. Content-Type was 'text/plain'. at RestApiIT.assertRunningJobSlotUsageEndpoint(RestApiIT.java:1528) ``` This is the PR's own new test, and it is a real finding, not a flake. `assertRunningJobSlotUsageEndpoint` is called first against the v1 Hazelcast-port URL (`HOST + hazelcastPort + CONTEXT_PATH + REST_URL_RUNNING_JOBS_SLOT_USAGE`, RestApiIT.java:431-434), served by `RestHttpGetCommandProcessor.handleRunningJobSlotUsage` -> `prepareResponse(command, runningJobSlotUsageService.getRunningJobSlotUsageJson())` (RestHttpGetCommandProcessor.java:261). I compared this against every other place in `RestApiIT` that uses the same strict `.as(TypeRef...)` deserialization (`getCheckpointOverview`/`getCheckpointHistory`, lines 1566-1580): both of those are only ever invoked with `buildHttpBaseUrl(httpPort)`, i.e. the Jetty v2 endpoint, never the v1 hazelcastPort path. `BaseServlet.writeJsonString` (the v2 path) explicitly sets `Content-Type: application/json` before writing; nothing in this diff shows the v1 `prepareResponse(command, String)` call site doing the same. So this looks like this new test is the first place in the suite that ever exercises strict-JSON deserialization against the v1 hazelcastPort REST stack for this endpoint, and it surfaces a genuine Content-Type mismatch there. Worth confirming against Hazelcast's `HttpCommandProcessor.prepareResponse(TextCommand, String)` behavior directly, but from this side of the code the fix is either to set the JSON content type explicitly on that response, or to have the v1 handler go through the same JSON-typed `prepareResponse` overload the other JSON endpoints use. - `all-connectors-it-2` (JDK 8) fails on a Couchbase container auth/timeout (`UnambiguousTimeoutException` / "Authentication Failure" against `e2e_couchbase:11210`) and `rocketmq-connector-it` (both JDK 8/11) fails on `RocketMqIT.testSourceRocketMqRestore` (`Expected: 45, actual: 55`). Both are unrelated to this PR's connector-http/engine changes and match known environmental/flaky failure patterns in this suite (Couchbase container bootstrap, RocketMQ restore dedup) — not blocking findings against this diff. Bottom line: the Aug 24 compile blocker is resolved, but the head is not green, and the new `testGetRunningJobSlotUsage` failure is a real, PR-relevant issue in the v1 REST path that needs a fix before this is mergeable. I'll re-trace once a fix for the Content-Type mismatch is pushed. -- 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]
