Repository navigation
feat(workflow): match search and listings against the copy on show - #8576
yangzhang75 wants to merge 3 commits into
Conversation
Automated Reviewer SuggestionsBased on the
|
|
| config | throughput | MB/s | latency | max Δ latest / 7d | |
|---|---|---|---|---|---|
| 🔴 | bs=10 sw=10 sl=64 | 446 | 0.272 | 21,943/25,742/25,742 us | 🟢 -23.0% / 🔴 +99.5% |
| 🔴 | bs=100 sw=10 sl=64 | 930 | 0.567 | 102,679/157,278/157,278 us | 🔴 +35.5% / 🔴 +67.7% |
| 🔴 | bs=1000 sw=10 sl=64 | 1,131 | 0.69 | 871,903/1,037,687/1,037,687 us | 🔴 +13.2% / 🔴 +14.7% |
Baseline details
Latest main b43d465 from same runner
| config | metric | PR | latest main | 7d avg | Δ latest | Δ 7d |
|---|---|---|---|---|---|---|
| bs=10 sw=10 sl=64 | throughput | 446 tuples/sec | 444 tuples/sec | 963.37 tuples/sec | +0.5% | -53.7% |
| bs=10 sw=10 sl=64 | MB/s | 0.272 MB/s | 0.271 MB/s | 0.588 MB/s | +0.4% | -53.7% |
| bs=10 sw=10 sl=64 | p50 | 21,943 us | 20,661 us | 10,998 us | +6.2% | +99.5% |
| bs=10 sw=10 sl=64 | p95 | 25,742 us | 33,434 us | 13,515 us | -23.0% | +90.5% |
| bs=10 sw=10 sl=64 | p99 | 25,742 us | 33,434 us | 16,850 us | -23.0% | +52.8% |
| bs=100 sw=10 sl=64 | throughput | 930 tuples/sec | 1,006 tuples/sec | 1,235 tuples/sec | -7.6% | -24.7% |
| bs=100 sw=10 sl=64 | MB/s | 0.567 MB/s | 0.614 MB/s | 0.754 MB/s | -7.7% | -24.8% |
| bs=100 sw=10 sl=64 | p50 | 102,679 us | 98,685 us | 87,833 us | +4.0% | +16.9% |
| bs=100 sw=10 sl=64 | p95 | 157,278 us | 116,092 us | 93,795 us | +35.5% | +67.7% |
| bs=100 sw=10 sl=64 | p99 | 157,278 us | 116,092 us | 103,718 us | +35.5% | +51.6% |
| bs=1000 sw=10 sl=64 | throughput | 1,131 tuples/sec | 1,148 tuples/sec | 1,273 tuples/sec | -1.5% | -11.1% |
| bs=1000 sw=10 sl=64 | MB/s | 0.69 MB/s | 0.701 MB/s | 0.777 MB/s | -1.6% | -11.2% |
| bs=1000 sw=10 sl=64 | p50 | 871,903 us | 867,764 us | 861,707 us | +0.5% | +1.2% |
| bs=1000 sw=10 sl=64 | p95 | 1,037,687 us | 916,457 us | 904,523 us | +13.2% | +14.7% |
| bs=1000 sw=10 sl=64 | p99 | 1,037,687 us | 916,457 us | 931,473 us | +13.2% | +11.4% |
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,448.87,200,128000,446,0.272,21942.79,25741.92,25741.92
1,100,10,64,20,2151.68,2000,1280000,930,0.567,102679.42,157278.45,157278.45
2,1000,10,64,20,17680.17,20000,12800000,1131,0.690,871903.40,1037686.67,1037686.67
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8576 +/- ##
============================================
- Coverage 92.73% 92.72% -0.01%
- Complexity 4947 4954 +7
============================================
Files 1241 1242 +1
Lines 52608 52788 +180
Branches 6507 6543 +36
============================================
+ Hits 48785 48950 +165
- Misses 2206 2212 +6
- Partials 1617 1626 +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:
|
3d82740 to
5d4e022
Compare
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>
5d4e022 to
02a567b
Compare
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?
19 new cases in
WorkflowPublishSpecplusWorkflowSearchQueryBuilderSpecandUnifiedResourceSchemaSpec(567 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