feat(workflow): match search and listings against the copy on show - #8576
Draft
yangzhang75 wants to merge 3 commits into
Draft
yangzhang75 wants to merge 3 commits into
yangzhang75 wants to merge 3 commits into
Conversation
A public workflow follows the author's latest content, as publishing has
always done. This adds the other state: the author pins the version they
have now, and the public copy stops moving until they pin again.
`is_public` stays the on/off switch; `published_content` is the pin, NULL
while following. `WorkflowPublishService` owns the two states, and three
endpoints expose them: POST and DELETE `/workflow/pin/{wid}` to pin and
unpin, GET `/workflow/publish-status/{wid}` for what the author is shown.
Publishing and unpublishing move through the same service, so unpublishing
drops the pin rather than leaving a private workflow carrying one.
Two paths are narrowed so a pin can hold. A save wrote the whole row back,
so a publish landing while a save was in flight was silently rolled back,
and a request body could set the publish columns itself; saves now write
only name, description and content. Creating a workflow clears the publish
columns for the same reason.
Nothing reads the pinned copy yet: every workflow is in the following
state it is in today, and nothing on screen changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
With a version pinned, a workflow has two copies: the author's working copy and the frozen one on public show. This routes every read that serves a viewer without granted access through the frozen copy, and freezes the name and description with the graph. `WorkflowPublishService.publicCopyOf` returns the three fields as a group, so a surface cannot pick up the published graph under a title the author has not published; `WorkflowAccessResource.hasGrantedAccess` is the seam that decides which copy a caller gets. Granted access -- owner, shared, project member -- keeps tracking the author's latest, because sharing is not publishing. Name and description freeze because they are as public as the graph: if only the graph froze, a report about a title could be answered by editing the title while the pinned copy still advertised it. Routed through it: opening a workflow, the hub's read, Clone, Duplicate, `/workflow_name`, `/workflow_description` and the size a listing shows. A workflow that follows the author's latest -- every workflow today -- is served exactly what it is served now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Search and the listings it feeds were reading the author's live columns, which for a pinned workflow is the one copy the public cannot open. A draft would turn up in a public search under a title nobody has seen, and the card would advertise a name the detail page does not show. Each filter is now applied to whichever copy the caller may see: `onVisibleCopy` builds the same filter twice -- over the live columns for rows the caller was granted access to, over the frozen ones for rows they reach only because the workflow is public -- and ORs the two. A disjunction over bare columns rather than a CASE, so each side stays eligible for its own fulltext index. Unpinned public rows fall back to the live columns, so a following workflow searches exactly as it does now. Listings carry two more things from the same query: the frozen name and description to show a viewer without granted access, and whether the copy on show is behind the author's working copy. `constructWhereClause` takes `includePublic` for this; the other builders accept and ignore it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Automated Reviewer SuggestionsBased on the
|
Contributor
|
| config | throughput | MB/s | latency | max Δ latest / 7d | |
|---|---|---|---|---|---|
| 🔴 | bs=10 sw=10 sl=64 | 452 | 0.276 | 20,129/35,033/35,033 us | 🔴 +31.1% / 🔴 +133.9% |
| 🔴 | bs=100 sw=10 sl=64 | 1,104 | 0.674 | 84,259/120,045/120,045 us | 🔴 +33.8% / 🔴 +20.1% |
| ⚪ | bs=1000 sw=10 sl=64 | 1,379 | 0.842 | 722,658/783,066/783,066 us | ⚪ within ±5% / 🟢 +22.3% |
Baseline details
Latest main 471e53c from same runner
| config | metric | PR | latest main | 7d avg | Δ latest | Δ 7d |
|---|---|---|---|---|---|---|
| bs=10 sw=10 sl=64 | throughput | 452 tuples/sec | 468 tuples/sec | 839.58 tuples/sec | -3.4% | -46.2% |
| bs=10 sw=10 sl=64 | MB/s | 0.276 MB/s | 0.286 MB/s | 0.512 MB/s | -3.5% | -46.1% |
| bs=10 sw=10 sl=64 | p50 | 20,129 us | 22,677 us | 11,937 us | -11.2% | +68.6% |
| bs=10 sw=10 sl=64 | p95 | 35,033 us | 26,721 us | 14,976 us | +31.1% | +133.9% |
| bs=10 sw=10 sl=64 | p99 | 35,033 us | 26,721 us | 19,204 us | +31.1% | +82.4% |
| bs=100 sw=10 sl=64 | throughput | 1,104 tuples/sec | 1,249 tuples/sec | 1,096 tuples/sec | -11.6% | +0.7% |
| bs=100 sw=10 sl=64 | MB/s | 0.674 MB/s | 0.763 MB/s | 0.669 MB/s | -11.7% | +0.7% |
| bs=100 sw=10 sl=64 | p50 | 84,259 us | 80,267 us | 94,033 us | +5.0% | -10.4% |
| bs=100 sw=10 sl=64 | p95 | 120,045 us | 89,715 us | 99,939 us | +33.8% | +20.1% |
| bs=100 sw=10 sl=64 | p99 | 120,045 us | 89,715 us | 110,148 us | +33.8% | +9.0% |
| bs=1000 sw=10 sl=64 | throughput | 1,379 tuples/sec | 1,411 tuples/sec | 1,128 tuples/sec | -2.3% | +22.3% |
| bs=1000 sw=10 sl=64 | MB/s | 0.842 MB/s | 0.861 MB/s | 0.688 MB/s | -2.2% | +22.3% |
| bs=1000 sw=10 sl=64 | p50 | 722,658 us | 704,548 us | 921,191 us | +2.6% | -21.6% |
| bs=1000 sw=10 sl=64 | p95 | 783,066 us | 784,331 us | 959,735 us | -0.2% | -18.4% |
| bs=1000 sw=10 sl=64 | p99 | 783,066 us | 784,331 us | 988,604 us | -0.2% | -20.8% |
Raw CSV
config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,442.35,200,128000,452,0.276,20129.49,35033.47,35033.47
1,100,10,64,20,1811.82,2000,1280000,1104,0.674,84259.45,120045.01,120045.01
2,1000,10,64,20,14504.66,20000,12800000,1379,0.842,722657.63,783065.80,783065.80
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8576 +/- ##
============================================
- Coverage 92.91% 92.76% -0.15%
- Complexity 4884 4908 +24
============================================
Files 1224 1226 +2
Lines 51298 51600 +302
Branches 6322 6368 +46
============================================
+ Hits 47664 47869 +205
- Misses 2070 2158 +88
- Partials 1564 1573 +9
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this PR?
A listing is where most people meet a workflow, so it has to agree with what opening it shows.
This makes search and the hub match, display and link against the copy on show.
workflows and public ones, so the filter is a disjunction of guarded filters — the working copy
for rows they were granted, the frozen copy for rows they reach only because those are public.
Written over bare columns rather than a
CASE, so each side stays eligible for its own PGroongaindex. A pinned workflow no longer turns up on keywords that exist only behind the pin, and the
author still finds their own work on what they just typed.
copy the detail page serves, so a card cannot advertise a title that opening it does not show.
Both are NULL while following, which leaves the live values in place.
author too: they are looking at the shelf, not at their own dashboard.
WorkflowPublishService.pinDiffersFromWorkingCopyis the share dialog's comparison as a SQL condition, and the search projection and the hub
listing both use it, so a card and the dialog cannot disagree about whether edits are held back.
Any related issues, documentation, discussions?
Closes #7940
Part of #7828. Design discussion: #7128. Stacked on #7853 and #8575; until those merge this PR
shows their commits too, and the review here is the last one.
How was this PR tested?
22 new cases in
WorkflowPublishSpecplusWorkflowSearchQueryBuilderSpecandUnifiedResourceSchemaSpec(559 in the dashboard package):matching it on its published copy — content, name and description, each separately;
their own workflow on a name only they can see;
ones, and a private workflow's own listing untouched;
nothing frozen, and equal to what the share dialog reports for the same workflow — including
after a rename and after a change of view, the two fields most easily left out of one of the
three places that answer this.
The shared condition was checked by mutation: dropping the default-view term from it turns the
card-versus-dialog case red.
scalafmtCheckAllclean.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)
🤖 Generated with Claude Code