The GitHub Actions job "Required Checks" on 
texera.git/gh-readonly-queue/main/pr-7580-befcf3f0813371c8dd351bc962b70c1bdc94f4b1
 has failed.
Run started by GitHub user aglinxinyuan (triggered by aglinxinyuan).

Head commit for run:
c7e7362a4022d41238227f47ec474dadd225150e / Eugene Gu <[email protected]>
test(computing-unit): extend ComputingUnitManagingResourceSpec to cover the 
create, rename and configuration endpoints (#7580)

### What changes were proposed in this PR?

This PR extends `ComputingUnitManagingResourceSpec` (added in #6853,
extended in #7337) to the endpoints of `ComputingUnitManagingResource`
that had no coverage. The existing spec only covered
`getComputingUnitInfo`, `getComputingUnitMetricsEndpoint`,
`listComputingUnits` and `terminateComputingUnit`; the create, rename
and configuration endpoints were untested.

All new tests keep the existing spec's approach: local-type units driven
against the embedded Postgres (`MockTexeraDB`), so no Kubernetes calls
are made. New coverage, by endpoint:

- **createWorkflowComputingUnit** — local happy path (persisted with a
generated `cuid`, the user URI landing in both the `uri` column and the
resource JSON's `nodeAddresses`, response reporting owner/WRITE/Running
with NaN metrics); whitespace-only name rejected with
`ForbiddenException` and nothing stored; unknown type (`quantum`)
rejected; `kubernetes` type rejected while disabled; missing and blank
URI rejected; the per-user running-unit quota not applying to local
units.
- **renameComputingUnit** — owner success; non-owner without access 403
(name kept); READ-only grantee 403; WRITE grantee success; blank name
400; nonexistent unit `NotFoundException`; database failure (name
overflowing the VARCHAR(128) column) rolling back and keeping the name;
and an admin who neither owns nor was granted access getting 403
(rename, unlike terminate, has no ADMIN bypass).
- **terminateComputingUnit** — a WRITE grantee rejected with 400 and the
unit not terminated (terminate requires strict ownership or the ADMIN
role).
- **getComputingUnitInfo** — a READ grantee sees the unit with `isOwner
= false` and `accessPrivilege = READ`; a nonexistent unit yields
`NotFoundException`; the owner response also reports the non-empty owner
avatar.
- **getComputingUnitTypes** — lists exactly `local` while Kubernetes is
disabled.
- **getComputingUnitLimitOptions** — returns the configured
cpu/memory/gpu option lists.
- **getComputingUnitResourceLimit** — the local branch returns NaN
limits for the owner; a non-owner gets `BadRequestException`; a
nonexistent unit yields `NotFoundException`.
- **getComputingUnitMetricsEndpoint** — adds the missing negative
direction: a non-owner gets `BadRequestException`.

Note: the Kubernetes-only validation in `createWorkflowComputingUnit`
sits behind the supported-type gate and is unreachable while
`kubernetes.enabled` is false; that flag is a load-time val the test JVM
does not override, so those branches cannot be exercised in this suite.
A spec comment records this.

No production code is changed.

### Any related issues, documentation, discussions?

Closes #7576

### How was this PR tested?

This PR is itself test-only. The new specs were run with:

```
sbt "ComputingUnitManagingService/testOnly 
org.apache.texera.service.resource.ComputingUnitManagingResourceSpec"
```

All 31 tests pass (7 pre-existing + 24 new) against the embedded
database; no external services are needed. The suite was
mutation-checked: targeted mutations of the resource (removing the
blank-name and missing-URI checks, inverting the rename ownership gate,
skipping the rename blank-name 400, making `getComputingUnitTypes` also
return `kubernetes`, and removing the non-owner check in
`getComputingUnitResourceLimit`) each caused at least one new test to
fail, and the source was restored afterwards.
`ComputingUnitManagingService/Test/scalafmtCheck` passes.

### Was this PR authored or co-authored using generative AI tooling?

Co-authored by: Claude Code (Claude Fable 5)

Report URL: https://github.com/apache/texera/actions/runs/31670574631

With regards,
GitHub Actions via GitBox

Reply via email to