aglinxinyuan opened a new pull request, #7239: URL: https://github.com/apache/texera/pull/7239
### What changes were proposed in this PR? `HubResource` was the largest untested class in the repo — **166 lines, 0% covered** — while its three siblings in the same package were already done: | Class | Coverage | |---|---| | `ActionType` | 100% | | `EntityType` | 100% | | `EntityTables` | 92.3% | | `HubResource` | **0%** | The three existing hub specs are pure in-memory tests of dispatch and Jackson round-trips; none touches `HubResource`, so there is no overlap. It is worth real tests rather than a coverage pass. It is not bulk jOOQ CRUD but ~14 methods of dispatch, validation and aggregation that happen to persist through jOOQ. 41 tests against `MockTexeraDB` (in-JVM embedded Postgres, per-suite database, no Docker) cover: - per-entity-type table dispatch for likes, clones and view counts — including that workflow and dataset counts stay apart when their ids collide - the IPv4 guard on the audited remote address - like/unlike idempotence against the `(uid, wid)` primary key - clone auditing: every attempt is audited, but only one clone row per user survives - the view-count backfill, **and** its suppression when `view` is not among the requested actions - `getTops` ranking, its public-only filter, and its limit fallback - the batch `getCounts` request-validation guards - `userAccess` de-duplication and per-entity access-table routing **Assertion strength was measured, not claimed.** 23 mutations of `HubResource` across three batches; every predicted red was observed and there were no collateral failures. A sample: | Mutation | Result | |---|---| | `ipv4Pattern.matches()` → `userIp != null` | red — ip column no longer left null for `::1` | | `if (isLike && !alreadyLiked)` → `if (isLike)` | red — duplicate-key violation | | `getTops orderBy(count.desc())` → `asc()` | red — wrong two workflows returned | | `getCounts` view-backfill made unconditional | red — proves the absence assertion is not vacuous | | `userAccess` dataset branch → workflow tables | red — grantees crossed between entities | | `recordUserAction` resource type hard-coded | red — equal ids no longer kept apart | Two empty-input tests are explicitly commented as pinning the contract (empty in, empty out) rather than the early-return branch, because jOOQ renders an empty `IN` list as a false predicate and the query returns empty with or without the guard. Flagging that rather than letting the test name overclaim. One production oddity surfaced and is documented in the spec rather than pinned: `WorkflowResource`'s `isOwner` uses `workflowRecord.into(WORKFLOW_OF_USER).getUid.eq(uid)` — Scala's `AnyRef.eq`, i.e. reference comparison on boxed `Integer`s, which is only reliable inside the −128..127 `Integer` cache. Demonstrated by experiment: with uids 71001/71002 two `isOwner shouldBe true` assertions fail while `ownerId` compares equal one line earlier; with uids 101/102 they pass. The spec asserts only the negatives, which survive a value-equality fix. No production file is touched. ### Any related issues, documentation, discussions? Closes #7236 ### How was this PR tested? 41 new tests. Run with the three pre-existing hub specs to confirm no interference — 83 tests, Java 17: ``` sbt "WorkflowExecutionService/testOnly org.apache.texera.web.resource.dashboard.hub.*Spec" ``` ``` [info] Suites: completed 4, aborted 0 [info] Tests: succeeded 83, failed 0, canceled 0, ignored 0, pending 0 [info] All tests passed. ``` `Test/scalafmtCheck` and `Test/scalafix --check` both `[success]`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 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]
