davidzollo opened a new pull request, #12098:
URL: https://github.com/apache/seatunnel/pull/12098

   ## Purpose
   
   Adds E2E regression coverage for the slot-release bug fixed in #6763
   ("[fix][zeta] fix can't release resource issue"), reported in #6761.
   
   Before that fix: when `seatunnel.engine.slot-service.slot-num` was set
   smaller than a job's actual slot requirement, the slots that had already
   been successfully granted before the shortfall was detected were never
   released. `ResourceUtils#applyResourceForPipeline` joined every per-task
   resource future, but a failed or missing future was silently dropped
   instead of triggering release of the ones that did succeed, so
   `NoEnoughResourceException` propagated with those already-granted slots
   still marked owned — permanently, since nothing ever released them.
   
   ## What was still missing
   
   `SeaTunnelSlotIT#testSlotNotEnough` already asserts the job reaches
   `FAILED` in this exact scenario (undersized fixed slot pool), but that
   assertion alone cannot distinguish a clean failure from a leaked one —
   both look identical from the job's own terminal status. The only test
   the original fix shipped with, `FixSlotResourceTest#testNotEnoughResource`
   in seatunnel-engine-server, asserts the release directly against a
   mocked, single-JVM `ResourceManager`. Neither proves a real cluster's
   slot pool is actually usable again afterward.
   
   ## What this test does
   
   `SeaTunnelSlotIT#testSlotReleasedAfterNotEnoughResourceFailure`:
   
   1. Drives the exact same undersized-cluster failure as
      `testSlotNotEnough` (slot-num 3, `batch_slot_not_enough.conf`, which
      needs more than 3), and waits for it to reach `FAILED`.
   2. Submits a second, minimal single-parallelism job
      (`batch_fake_to_console_minimal_slot.conf`) against the same
      still-running cluster, and asserts it reaches `FINISHED`.
   
   If the first job's slots were never released, the cluster would still
   show 0 free slots and the second job would fail with the same
   `NoEnoughResourceException` instead of completing — this closes the gap
   functionally, without needing to reach into internal resource-manager
   bookkeeping.
   
   ## Test plan
   
   - New test method + one new minimal test-resource config; no production
     code changed.
   - `./mvnw spotless:apply` run on the affected module — succeeded.
   - `./mvnw install -DskipTests` (module + dependency chain,
     `seatunnel-engine-ui` excluded since unmodified) run to confirm the
     new/changed code genuinely compiles — confirmed via `BUILD SUCCESS`
     and the actual `.class` file present under `target/test-classes` (not
     run with `-Dmaven.test.skip=true`, which skips test compilation
     entirely rather than just execution).
   - Full test execution is left to CI per this repository's E2E
     conventions (Hazelcast-cluster-backed, not run in this sandbox).


-- 
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]

Reply via email to