This is an automated email from the ASF dual-hosted git repository. github-merge-queue[bot] pushed a commit to branch gh-readonly-queue/main/pr-7633-86dd852085db10e8fe7c2db59a9232ef8347eb67 in repository https://gitbox.apache.org/repos/asf/texera.git
commit eefd8600b6cf75da9e5d3067bc531ac3bc4faba9 Author: Xinyuan Lin <[email protected]> AuthorDate: Thu Aug 13 06:49:49 2026 +0000 fix(computing-unit): repair the owner-avatar accessor in the spec (#7633) ### What changes were proposed in this PR? **`main` does not compile.** Any PR whose `build / amber` or `build / amber-integration` jobs run after this landed fails on it regardless of what the PR itself touches — #7631 is an example, where the only change is four tests in an unrelated module's spec. Scoping that honestly: PRs whose amber jobs ran *before* the breakage still show green and would fail on re-run, and frontend-labelled PRs skip the amber stack, so this is "every amber run from now until it is fixed" rather than "every open PR is red today". `ComputingUnitManagingResourceSpec` asserts on `DashboardWorkflowComputingUnit.ownerGoogleAvatar`, but the field is named `ownerAvatar`, so `ComputingUnitManagingService / Test` fails with two "value ownerGoogleAvatar is not a member" errors. Two PRs raced to produce it: #7563 renamed the field to `ownerAvatar`, while #7580 added assertions written against the old name. Each was green against its own base, and the combination is what breaks — the kind of thing per-PR CI cannot see when two PRs touch different files. This renames the two accessor calls. Nothing else changes. ### How was this PR tested? Confirmed the breakage is real and that this is the whole of it, by stashing the change and re-running on otherwise-clean `main`: ``` sbt "ComputingUnitManagingService/Test/compile" ``` | | Result | |---|---| | unpatched `main` | exit 1, exactly 2 × `value ownerGoogleAvatar is not a member` | | with this change | exit 0, compiles clean | Then the spec itself: ``` sbt "ComputingUnitManagingService/testOnly org.apache.texera.service.resource.ComputingUnitManagingResourceSpec" ``` ``` [info] Total number of tests run: 31 [info] Tests: succeeded 31, failed 0, canceled 0, ignored 0, pending 0 ``` All 31 pass, so the assertions were correct about the value and only the accessor name was stale. `Test/scalafmtCheck` and `Test/scalafix --check` both pass. ### Any related issues, documentation, discussions? Closes #7632 ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) --- .../texera/service/resource/ComputingUnitManagingResourceSpec.scala | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/computing-unit-managing-service/src/test/scala/org/apache/texera/service/resource/ComputingUnitManagingResourceSpec.scala b/computing-unit-managing-service/src/test/scala/org/apache/texera/service/resource/ComputingUnitManagingResourceSpec.scala index 5b7c64104a..4cbb0e0781 100644 --- a/computing-unit-managing-service/src/test/scala/org/apache/texera/service/resource/ComputingUnitManagingResourceSpec.scala +++ b/computing-unit-managing-service/src/test/scala/org/apache/texera/service/resource/ComputingUnitManagingResourceSpec.scala @@ -176,7 +176,7 @@ class ComputingUnitManagingResourceSpec info.isOwner shouldBe true info.accessPrivilege shouldBe PrivilegeEnum.WRITE info.ownerName shouldBe "owner" - info.ownerGoogleAvatar shouldBe "owner-avatar" + info.ownerAvatar shouldBe "owner-avatar" } it should "report READ access for a grantee holding READ access" in { @@ -282,7 +282,7 @@ class ComputingUnitManagingResourceSpec created.accessPrivilege shouldBe PrivilegeEnum.WRITE created.ownerName shouldBe "creator" // makeUser sets no avatar, so the owner-avatar lookup resolves to null - created.ownerGoogleAvatar shouldBe null + created.ownerAvatar shouldBe null // The unit is persisted, not just echoed back unitName(cuid) shouldBe "local-cu"
