eugenegujing opened a new pull request, #7580:
URL: https://github.com/apache/texera/pull/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)


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