This is an automated email from the ASF dual-hosted git repository.
github-merge-queue[bot] pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/texera.git
The following commit(s) were added to refs/heads/main by this push:
new eefd8600b6 fix(computing-unit): repair the owner-avatar accessor in
the spec (#7633)
eefd8600b6 is described below
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"
