aglinxinyuan commented on PR #7239:
URL: https://github.com/apache/texera/pull/7239#issuecomment-5150875274

   Done — rebased onto main and reworked as a fold in 454c93fbeb. The file is 
no longer re-added; #7230's spec is the base and its 11 tests are untouched.
   
   The load-bearing number is `git diff --numstat`: **656 insertions, 0 
deletions**. Every line of the merged file — imports, the 
`ownerUid`/`likerUid`/`wid`/`Wf` constants, 
`req`/`session`/`makeUser`/`ids`/`types`/`actions`/`likeRows`/`cloneRows`/`userActionRows`/`isLiked`,
 the `beforeAll` seed, the four `beforeEach` deletes and all 11 test bodies — 
is byte-identical to `origin/main`. New cases attach to the existing subject 
groups with `it should ...`, so no subject string is duplicated.
   
   All six areas you named are folded in, plus the rest that was additive:
   
   | Area | Cases |
   |---|---|
   | `recordUserAction` | IPv4 guard; per-entity-type tagging so equal ids stay 
apart |
   | per-entity table dispatch | likes, view counts and access routed by entity 
type, incl. a workflow and dataset sharing id `830001` |
   | `getCounts` | validation guards; default vs filtered action sets; 
zero-view backfill **and** its suppression when `view` isn't requested; absent 
clone table; one response per pair |
   | `getTops` | ranking; limit + fallback; public-only filter; clone bucket; 
unsupported action types |
   | `userAccess` | per-entity access tables; empty grantee list; 
de-duplication |
   | plus | `recordLikeAction` audit trail, `isLikedHelper`, `getCount` 
dataset-vs-workflow, `postView` auditing, `fetchDashboardWorkflowsByWids` 
hydration |
   
   **Six of my original cases were dropped as restatements of yours** — the 
like insert/remove pair, the already-liked false, the clone row+action, the 
postLike/postUnlike toggle, and the first-view running total. Where one of 
those carried a unique assertion (e.g. that a *rejected* duplicate like writes 
no audit row) I folded that assertion into a kept test rather than keeping the 
duplicate test.
   
   Two fixture changes, both additive:
   - `beforeEach` gains three deletes (`USER_ACTION` where `resource_id != 
wid`, `WORKFLOW` where `wid != 7001`, and `DATASET`) so the new seeds can't 
leak between tests. Your four deletes are unchanged, and wid 7001 plus its 
ownership/access rows are spared, so `getCount should count the public 
workflows` still sees exactly 1. Checked against `texera_ddl.sql` that the 
parent deletes cascade to the likes/clones/view-count/access children; 
`user_action` has no FK, hence its own delete.
   - `beforeAll` gains one user, uid 9003. Genuinely needed: likes are PK 
`(uid, wid)`, so a strict 3 > 2 > 1 ranking is impossible with two users, and 
the `userAccess` dispatch case needs disjoint grantee sets.
   
   Re-verified after the fold — 89 tests across the four hub specs, 
`scalafmtCheck` and `scalafix --check` clean. I also re-ran the mutation check 
against the folded file: neutering the IPv4 guard, changing the `getTops` limit 
fallback `8 → 4`, and dropping `.distinct` in `userAccess` each turned 
**exactly** the expected test red and nothing else (44 passed / 3 failed). All 
three reverted; the production diff is empty.
   
   One thing worth flagging since your fixture uids feed into it: 
`fetchDashboardWorkflowsByWids` reports `isOwner` via 
`workflowRecord.into(WORKFLOW_OF_USER).getUid.eq(uid)` 
(`WorkflowResource.scala:252`) — that's Scala's `AnyRef.eq`, i.e. reference 
comparison on boxed `Integer`s, so it's only reliable inside the −128..127 
`Integer` cache. With uids in the 9001–9003 range the real owner reports 
`isOwner == false`. I've asserted only the two negatives (different uid, null 
uid), which survive a value-equality fix, and left a comment saying why there's 
no positive assertion. Happy to open a separate issue for it.
   


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